Perl 2003 date problem

software development

#1

For some reason, I can’t get Perl to return a valid date. The current year always comes out as 103 rather than 2003. Is this a known bug in Perl? Or an OS problem? Or am I doing something wrong?

(I have actually noticed something similar to this in some unix based apps at work, and I think we have a problem record open with the vendor)

Example:

#!/usr/bin/perl

($Second, $Minute, $Hour, $Day, $Month, $Year, $WeekDay, $DayOfYear, $IsDST)
= localtime(time);

print “$Year\n”;

exit (0);

103

Any help appreciated. Does someone have a elegant way to get the current UTC time in the ISO format (eg “2003-01-25 13:45:01”)? Are the servers system clocks set to GMT?

Thanks - Zilch.


#2

Have a look into the Date::* class of modules availavle on CPAN. Date::Simple will do fine for what you’re trying to do:

http://search.cpan.org/author/JTOBEY/Date-Simple-2.04/lib/Date/Simple.pm

To get your snippet to work add $Year += 1900;. Read up on the unix date and you’ll find out why this doesn’t return the current date, but rather the current date from a given period in time.

  • wil

#3

Wil - thanks for the reply. Blindingly obvious when I re-RTFM. I can’t use Date:Simple as it turns out because it doesn’t support the time component. I ended up using ParseDate from Date::Manip qw(ParseDate)

Having a $date variable with a three digit code for the current yeah seems rather odd, but then a lot of unix things do to me I guess.

Thanks for your help.

Zilch


#4

Most POSIX puters keep track of time by measuring the seconds, not including leapseconds, since the Epoch.

Since the Epoch occurred at midnight, December 31, 1969, it was generally easier for 20th-century programmers if dates were expressed as an offset from 1900, rather than 1970.

This isn’t universal, of course. MS-DOS expressed years as an offset from 1970.

Hang onto your hat, because it’s all going to need changed in a few years, anyway. The variable used to hold the number of seconds is going to run out of bits very soon now (in the 2030s?) and we’re going to have a new Y2Kish problem.

I expect that within a decade, there will be new POSIX date functions that are based on 4-year dates, so that with any luck, we’ll have discarded any old software well in advance, but there’s probably still going to be 1960s-era COBOL code around… (That, of course, predates POSIX, but the Y2K patches wouldn’t…)