This queue is for tickets about the OLE-Storage_Lite CPAN distribution.

Report information
The Basics
Id:
124513
Status:
resolved
Priority:
Low/Low

People
Owner:
jmcnamara [...] cpan.org
Requestors:
bitcardbmw [...] lsmod.de
Cc:
AdminCc:

BugTracker
Severity:
Important
Broken in:
0.19
Fixed in:
(no value)



Subject: dates misinterpreted after 2020
similar to https://rt.cpan.org/Public/Bug/Display.html?id=124508 after 2020-01-01 tests were failing because year 70 was now interpreted as 2070 # Failed test ' LocalDate2OLE: Thu Jan 1 00:00:00 1970 # at t/01_date_conversion.t line 40. # got: '0040352757CF0D02' # expected: '00803ED5DEB19D01' This patch fixed it for me, but it may change how an input of year=18 is parsed (1918 instead of 2018) Index: OLE-Storage_Lite-0.19/lib/OLE/Storage_Lite.pm =================================================================== --- OLE-Storage_Lite-0.19.orig/lib/OLE/Storage_Lite.pm +++ OLE-Storage_Lite-0.19/lib/OLE/Storage_Lite.pm @@ -1364,7 +1364,9 @@ sub LocalDate2OLE { return "\x00" x 8 unless $localtime; # Convert from localtime (actually gmtime) to seconds. - my $time = timegm( @{$localtime} ); + my @localtimecopy = @{$localtime}; + $localtimecopy[5] += 1900 unless $localtimecopy[5] > 99; + my $time = timegm( @localtimecopy ); # Add the number of seconds between the 1601 and 1970 epochs. $time += 11644473600;
On 2018-02-21 07:43:51, bmwiedemann wrote:
Show quoted text
> similar to https://rt.cpan.org/Public/Bug/Display.html?id=124508 > > after 2020-01-01 tests were failing because year 70 was now > interpreted as 2070 > > # Failed test ' LocalDate2OLE: Thu Jan 1 00:00:00 1970 > # at t/01_date_conversion.t line 40. > # got: '0040352757CF0D02' > # expected: '00803ED5DEB19D01' > > This patch fixed it for me, but it may change how an input of year=18 > is parsed (1918 instead of 2018) > > Index: OLE-Storage_Lite-0.19/lib/OLE/Storage_Lite.pm > =================================================================== > --- OLE-Storage_Lite-0.19.orig/lib/OLE/Storage_Lite.pm > +++ OLE-Storage_Lite-0.19/lib/OLE/Storage_Lite.pm > @@ -1364,7 +1364,9 @@ sub LocalDate2OLE { > return "\x00" x 8 unless $localtime; > > # Convert from localtime (actually gmtime) to seconds. > - my $time = timegm( @{$localtime} ); > + my @localtimecopy = @{$localtime}; > + $localtimecopy[5] += 1900 unless $localtimecopy[5] > 99; > + my $time = timegm( @localtimecopy ); > > # Add the number of seconds between the 1601 and 1970 epochs. > $time += 11644473600;
So, now it's 2020, and the test suite is really failing.
On 2020-01-01 12:50:55, SREZIC wrote:
Show quoted text
> On 2018-02-21 07:43:51, bmwiedemann wrote:
> > similar to https://rt.cpan.org/Public/Bug/Display.html?id=124508 > > > > after 2020-01-01 tests were failing because year 70 was now > > interpreted as 2070 > > > > # Failed test ' LocalDate2OLE: Thu Jan 1 00:00:00 1970 > > # at t/01_date_conversion.t line 40. > > # got: '0040352757CF0D02' > > # expected: '00803ED5DEB19D01' > > > > This patch fixed it for me, but it may change how an input of year=18 > > is parsed (1918 instead of 2018) > > > > Index: OLE-Storage_Lite-0.19/lib/OLE/Storage_Lite.pm > > =================================================================== > > --- OLE-Storage_Lite-0.19.orig/lib/OLE/Storage_Lite.pm > > +++ OLE-Storage_Lite-0.19/lib/OLE/Storage_Lite.pm > > @@ -1364,7 +1364,9 @@ sub LocalDate2OLE { > > return "\x00" x 8 unless $localtime; > > > > # Convert from localtime (actually gmtime) to seconds. > > - my $time = timegm( @{$localtime} ); > > + my @localtimecopy = @{$localtime}; > > + $localtimecopy[5] += 1900 unless $localtimecopy[5] > 99; > > + my $time = timegm( @localtimecopy ); > > > > # Add the number of seconds between the 1601 and 1970 epochs. > > $time += 11644473600;
> > So, now it's 2020, and the test suite is really failing.
CPAN.pm users may use the following distroprefs file for automatically applying the proposed patch: https://github.com/eserte/srezic-cpan-distroprefs/blob/master/OLE-Storage_Lite.yml
Thanks. Fixed in version 0.20 just uploaded to CPAN.


This service runs on Request Tracker, is sponsored by The Perl Foundation, and maintained by Best Practical Solutions.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.