This and other RFCs are available on the web at
http://dev.perl.org/rfc/

=head1 TITLE

Standardize ALL Perl platforms on UNIX epoch

=head1 VERSION

Maintainer: Nathan Wiger <nate@wiger.org>
Date: 14 Aug 2000
Last Modified: 28 Sep 2000
Mailing List: perl6-language-datetime@perl.org
Number: 99
Version: 4
Status: Frozen

=head1 ABSTRACT

Currently, internal time in Perl is maintained via C<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
example).

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).

=head1 DESCRIPTION

=head2 UNIX Epoch

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.

=head2 Other Time Properties

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.

=head2 Potential Time Object

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 C<time>. Note
that by creating a polymorphic object C<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.

=head1 IMPLEMENTATION

The C<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 C<time> and must be noted clearly
in the documentation.

The C<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 C<time> would appear
unchanged to all the Linux hackers, which is probably a good thing.

=head1 REFERENCES

RFC 7: Higher resolution time values

RFC 48: Replace localtime() and gmtime() with date() and utcdate()

RFC 159: True Polymorphic Objects

http://www.mail-archive.com/perl6-language-datetime%40perl.org/msg00001.html

http://www.mail-archive.com/perl6-language-datetime%40perl.org/msg00002.html

http://www.mail-archive.com/perl6-language-datetime%40perl.org/msg00025.html

http://www.mail-archive.com/perl6-language-datetime%40perl.org/msg00035.html

Search Discussions

  • Curtis Jewell at Sep 28, 2000 at 11:28 pm
    ----- Original Message -----
    From: "Perl6 RFC Librarian" <perl6-rfc@perl.org>
    To: <perl6-announce-rfc@perl.org>
    Cc: <perl6-language-datetime@perl.org>
    Sent: Thursday, September 28, 2000 14:37
    Subject: RFC 99 (v4) Standardize ALL Perl platforms on UNIX epoch

    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 C<time> would appear
    unchanged to all the Linux hackers, which is probably a good thing.
    Hmm... Isn't TAI->UTC RELATIVELY easy, but has accuracy loss? (I could be
    misinformed...) I'd just do two things, therefore:

    1. Define $time->tai (and the corresponding $time->utc) routine...

    2. STORE time as TAI (for accuracy), but RETURN it in "integer" SCALAR
    context (I assume other object methods return string SCALARS) as UTC (for
    consistency). Of course, specifying $time->tai overrides this, and the UTC
    value may be cached as needed to make this faster.

    --
    Curtis Jewell http://www.geocities.com/curtis_whalen/ csjc05@mizzou.edu
    http://new-york.utica.mission.net/ cjewell@mission.net
    No matter where we fall or where we land | curtis@mlug.missouri.edu
    I believe we're part of a master plan (from "Wonderland" on the Ptm2K OMPS)
  • Russ Allbery at Sep 28, 2000 at 11:38 pm

    Curtis Jewell writes:

    Hmm... Isn't TAI->UTC RELATIVELY easy, but has accuracy loss? (I could
    be misinformed...) I'd just do two things, therefore:
    TAI to UTC is easy and accurate if you have a current leap-seconds table.
    (In fact, in order to get TAI, you probably converted from UTC to TAI in
    the first place, since most available clocks tick UTC.)

    The problem with doing anything about leap seconds other than completely
    ignoring them is that you have to know when they occur, and they're not
    predictable in advance.

    The accuracy problems with UTC are more discontinuity problems than
    anything else. The problem with UTC is that it behaves very poorly from
    the perspective of a computer program around leap seconds.

    Actually, it's more complicated than that: UTC is really a specification
    of a human time scale; it's not defined in seconds since anything. It's
    defined in terms of hours, minutes, seconds, days, months, and years.
    Leap seconds are well-defined in that sort of system; the clock just ticks
    from 11:59:59 to 11:59:60 and then to 00:00:00. The problems with UTC are
    all caused by *conversion*; most Unix systems currently convert UTC into
    seconds since epoch without adjusting for any leap seconds.

    All Unix clocks are natively TAI, given that they don't adjust for leap
    seconds and tick forward one second every second. However, since most
    people actually keep UTC or a time zone based on UTC, what actually
    happens in practice is that when there's a UTC leap second, the Unix clock
    blissfully ignores it and then finds itself one second off of UTC after
    the leap second has passed, at which point xntpd or the like adjusts the
    clock as if it had skewed. This means that if you were measuring
    something during a period in which UTC had a leap second, your measurement
    may well end up off by a second depending on what xntpd did to your clock.

    (This is just my understanding from reading a lot of mailing list traffic
    and web pages on this; I may well have some of the details wrong and
    welcome corrections.)
    1. Define $time->tai (and the corresponding $time->utc) routine...
    2. STORE time as TAI (for accuracy), but RETURN it in "integer" SCALAR
    context (I assume other object methods return string SCALARS) as UTC
    (for consistency). Of course, specifying $time->tai overrides this, and
    the UTC value may be cached as needed to make this faster.
    I like this idea.

    --
    Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupperl6-language-datetime @
categoriesperl
postedSep 28, '00 at 7:37p
activeSep 28, '00 at 11:38p
posts3
users3
websiteperl6.org

People

Translate

site design / logo © 2021 Grokbase