Item6018: GMTIME{}% does not return the right value for $week in ISO8601
Priority: Normal
Current State: Closed
Released In: 1.0.2
Target Release: patch
Applies To: Engine
Component:
Branches:
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.
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:
- 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.
- 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
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