Item6018: GMTIME{}% does not return the right value for $week in ISO8601

In ISO 8601, the week with the first thursday in january is defined as the first week. The functions %GMTIME{"$week"}%, %DISPLAYTIME{"$week"}% %SERVERTIME{"$week"}% gave $week=53 for the date 2007-12-31, which is the american standard (for bookkeepers, I heared) and not ISO 8601.

The JSCalenderContrib returns "01" for the format variables %U %V %W for the date 2007-12-31, which is right.

• WolfgangRaus - 24 Sep 2008

In the meantime, I think I found the bug. In /lib/Twiki/Time.pm, starting with line 250, the routine is:

sub _weekNumber {
    my( $day, $mon, $year, $wday ) = @_;
    
    require Time::Local;

    # calculate the calendar week (ISO 8601)
    my $nextThursday = Time::Local::timegm(0, 0, 0, $day, $mon, $year) +
      (3 - ($wday + 6) % 7) * 24 * 60 * 60; # nearest thursday
    my $firstFourth = Time::Local::timegm(0, 0, 0, 4, 0, $year); # january, 4th
    return sprintf('%.0f', ($nextThursday - $firstFourth) / ( 7 * 86400 )) + 1;
}

This subroutine calculates the weeknumber always for the current year only.

There are mainly two solutions:

1. control wether today is in the range of yyyy-12-29 to yyyy-12-31, check the weekday and switch to weeknumber 01 of next year, if it is necessary.
2. new implementation with CPAN:Date::ISO, if coding-standards are allowing this.

I am not a programmer (although I am slowly learning Perl), so please feel free to solve this bug. If I do this by my own, we will have %WIKITOOLNAME v 3.0.0 or 2010.03.0

• WolfgangRaus - 2008-11-09

Fixed with some code from perl monks, which doesn't even use Time::Local.

-- CrawfordCurrie - 24 Feb 2009

Can't you guys learn to fill out the TargetRelease and ReleasedIn fields right? It is only 24 hours ago I told you guys that we missed more than 30 bugs in the release notes of 1.0.0 because these fields were blank. And then the day after I again have to add valid values to the fields.

-- KennethLavrsen - 24 Feb 2009