Skip Menu |

This queue is for tickets about the Time-y2038 CPAN distribution.

Report information
The Basics
Id: 43347
Status: stalled
Priority: 0/
Queue: Time-y2038

Owner: Nobody in particular
Requestors: perl [...]

Bug Information
Severity: Wishlist
Broken in: 20081111
Fixed in: (no value)

Subject: Doesn't work with times, requires dates.
Download (untitled) / with headers
text/plain 579b
Some modules such as POSIX::strptime return the date portion null to resemble just a time. I believe the ts struct spec permits this too. This module fails to handle this: Time::y2038::time(gm|local)( POSIX::strptime( "05:00:00", "%T" ) ); I've attached a perl test that demonstrates this. use Test::More tests=>3; require_ok('Time::y2038'); cmp_ok ( Time::y2038::timelocal( 0, 0, 5, (undef) x 5 ), '>', 0, 'T-y2038 fails timelocal() with date portion undef' ); cmp_ok ( Time::y2038::timegm( 0, 0, 5, (undef) x 5 ), '>', 0, 'T-y2038 fails timegm() with date portion undef' );
Subject: timelocal() requires all arguments
The test must have gotten lost. Show quoted text
> Some modules such as POSIX::strptime return the date portion null to > resemble just a time. I believe the ts struct spec permits this too.
You mean the tm struct? The POSIX docs for mktime() say "the original values of the other components are not restricted to the ranges described in <time.h>" which is usually taken to mean you can ask for October 32nd and it supposed to figure out you mean November 1st. As for what strptime() will do in this case, it will update your tm struct with whatever it finds. If you don't give it a year, it will leave the year alone. C has no concept of a null integer struct member, you can't set date->tm_year = NULL meaningfully, it will probably cast it to 0. So C has nothing to say about this case. POSIX::strptime's interface does not work like C's, so C cannot provide guidance to it. That's what C has to say about this, its impossible to get into this case. Now how about Perl? Time::Local has no special code for this case. It just dumbly takes undef to mean 0 and warns a lot. That's no help, but at least Time::y2038 is doing no worse. It seems there are three choices: 1) Treat the undefs as zeros. 2) Disallow the wrong number of arguments. 3) Fill in the missing arguments with the current date. #1 isn't very useful. You probably don't want the Unix time for 1900 or 2000 or any other fixed date. #2 is the current behavior, and at least it clearly errors out or throws a warning if you pass in undef. #3 is the most DWIM, but it can also mask mistakes if it translates undef. At this point I'm inclined to leave it as is rather than add in magic. Its kinda outside y2038's scope. If Time::Local changes its behavior in this respect then it becomes a compatibility issue. But where it is in scope is perl5i. I've always hated that Perl returns the date as a list instead of a hash ref (they didn't exist). It might be interesting to special case timelocal() to take a hash ref and fill in missing keys with the current date and time. localtime() already returns a DateTime object.

This service is sponsored and maintained by Best Practical Solutions and runs on infrastructure.

Please report any issues with to