One of the major outstanding issues is still exactly what clock Perl
intends to keep and return from the time command. There has been some
discussion of the difficulties in obtaining the Unix epoch on platforms
where the native system clock is not using the Unix epoch; Nathan, could
you update your RFC to include notes about that if possible?

Was there any resolution as to how one obtains the offset between the
system clock and the Unix epoch clock on a platform like Mac where
apparently the system clock is in local time and it may be difficult to
determine the time zone of the system?

Is Perl keeping UTC or TAI? If we're standardizing on an epoch, we should
also standardize on a clock; the difference is over ten seconds. If we're
isolating the programmer from system clock issues, should we try to
isolate them from weird handling of leap seconds?

I think that TAI vs. UTC could use its own RFC, but if no one has the time
to write it (I don't, myself), maybe Nathan could include at least a
mention of it as an issue?

There's also the question of whether to use libtai for the implementation;
this is a bit outside the scope of this working group, I think, but could
productively be the subject of an internals RFC.

Finally, on a separate note, does anyone have a pointer for the details on
how to write working group summaries? I need to write one up and I can't
find details on format and address to send it to on dev.perl.org. Danke.

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

Search Discussions

  • Chris Nandor at Sep 21, 2000 at 8:33 pm

    At 16:09 -0700 2000.09.19, Russ Allbery wrote:
    Was there any resolution as to how one obtains the offset between the
    system clock and the Unix epoch clock on a platform like Mac where
    apparently the system clock is in local time and it may be difficult to
    determine the time zone of the system?
    Well, the problem is not the Mac. The Mac returns proper values for gmtime
    and localtime, so you can claculate the difference. The problem is that we
    don't know if we can calculate the proper time on all platforms. Are there
    any that are unaccounted for at this point?

    Is Perl keeping UTC or TAI? If we're standardizing on an epoch, we should
    also standardize on a clock; the difference is over ten seconds. If we're
    isolating the programmer from system clock issues, should we try to
    isolate them from weird handling of leap seconds?
    I come out one second off in my calculation between Unix and Mac OS; I
    think this is a leap second issue. I don't know how important it is.

    --
    Chris Nandor pudge@pobox.com http://pudge.net/
    Open Source Development Network pudge@osdn.com http://osdn.com/
  • Nathan Wiger at Sep 24, 2000 at 10:46 pm

    Russ Allbery wrote:

    Is Perl keeping UTC or TAI? If we're standardizing on an epoch, we should
    also standardize on a clock; the difference is over ten seconds.
    I think we should definitely maintain this in UTC, since this is how
    UNIX works natively. If we're standardizing on the UNIX epoch we should
    standardize on UTC clock as well.

    I'm up to over 30 RFC's, so I don't have time to add this, but given the
    low traffic on this list I think we can consider it "duly noted", if
    that's ok with everyone.

    -Nate
  • Nathan Wiger at Sep 24, 2000 at 10:59 pm

    Nathan Wiger wrote:

    I think we should definitely maintain this in UTC, since this is how
    UNIX works natively. If we're standardizing on the UNIX epoch we should
    standardize on UTC clock as well.
    Blech. Now I'm not sure after re-reading the thread starting here:

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

    How about this: Somebody else decide and I'll stick it in as a not in v4
    of RFC 99, which will be the frozen version.

    -Nate

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupperl6-language-datetime @
categoriesperl
postedSep 19, '00 at 11:09p
activeSep 24, '00 at 10:59p
posts4
users3
websiteperl6.org

People

Translate

site design / logo © 2021 Grokbase