[% setvar title Standardize ALL Perl platforms on UNIX epoch %]
To see what is currently happening visit http://www.perl6.org/
Standardize ALL Perl platforms on UNIX epoch
Maintainer: Nathan Wiger <firstname.lastname@example.org> Date: 14 Aug 2000 Last Modified: 28 Sep 2000 Mailing List: email@example.com Number: 99 Version: 4 Status: Frozen
Currently, internal time in Perl is maintained via
time, which is
highly system-dependent. On some systems, this is relative to the UNIX
epoch, while others use their own epochs (MacPerl uses 1904, for
All versions of Perl on all platforms should maintain time both internally and externally as seconds since the UNIX epoch (00:00:00 01 Jan 1970 UTC).
Time is a dicey issue. While everyone disagrees on what the "right" epoch is to use, everyone generally agrees that time synchronization across different versions of Perl is a good thing.
The UNIX epoch is already a widely-established standard and seems as good as any. This has the added benefit that most users will see no change, since most users use a version of Perl which is already based on the UNIX epoch.
Everyone seems pretty well agreed that while they want a standard epoch, they also really want access to important alternative information, such as ISO and native system time.
There are three alternatives:
1. Do not provide this information 2. Add additional builtins to deal with this information 3. Make time into a function that returns a polymorphic object
Option 3 seems the most gracious, and nobody else was willing to even entertain numbers 1 or 2. As such, we'll explore what could be returned from said time object.
However, note this is only needed if we decide the other information is important enough to be core-worthy. The opinion seems split on this one.
A time object could, conceivably, look like this:
$t = time; # time object in scalar context $t++; # ->NUMBER, same as ->unix print "$t"; # ->STRING, same as ->unix $t->unix # UNIX epoch seconds $t->iso # ISO format $t->mjd # modified julian date $t->native # native time, whatever that may be
For example. Despite offering it up as a possibility, however, this RFC
does not strictly require a time object be returned from
that by creating a polymorphic object
time will look just like it
created a scalar to users, meaning they don't have to even know it's an
object if they don't want to.
time core function must be changed to return the number of
seconds since the UNIX epoch on ALL platforms. Note this behavior is
inconsistent with previous versions of
time and must be noted clearly
in the documentation.
time value should be maintained as a 64-bit int (or float) with a
ridiculous amount of precision, per RFC 7.
The issue is still open as to whether or not time should be maintained
internally via TAI or UTC. Both have their pros and cons. TAI is more
accurate, but does not have any close correlation to many platforms. UTC
has leap-second trickery, but has the distinct advantage that it would
remain consistent with UNIX platforms. This means
time would appear
unchanged to all the Linux hackers, which is probably a good thing.
RFC 7: Higher resolution time values
RFC 48: Replace localtime() and gmtime() with date() and utcdate()
RFC 159: True Polymorphic Objects