NOTICE: reply-to set to the -language-datetime list.

Ted Ashton writes:
Well then, why 1970? If we're defining our own, why buy into one
which is scheduled to blow up in 2038? Why not at the very least
start with Jan 1, 2K?
This works, provided epoch seconds are stored in some form of big
integers (either arbitrary precision, or 64-bit). The epoch change
would then be fine by me. But epoch changes don't solve the 2038
problem, Unix already tried that before the move to 32-bit integers
(they moved the epoch from 1970 to 1971, I think, when their previous
size of integer was about to run out of space, then when it ran out
again next year they said "yeah, ok, wrong solution" :-).

Nat

Search Discussions

  • Nathan Torkington at Aug 16, 2000 at 4:14 am
    (Reply-to set to -datetime list)

    Chaim Frenkel writes:
    NT> Epoch seconds are a convenient representation for dates and times.
    NT> Varying epochs make it an unreliable representation when data are
    NT> shared. A consistent epoch would fix this.

    Sorry, I don't buy that. Not every program will be perl.
    Bogus argument. This is a non-issue. I'm talking about it being
    easy to run the same program on different platforms but share data.
    Optimize for Perl.
    The only valid interchange would be to specify the date unambiguously,
    for example the ISO <mumble, help me Jarkko> YYYYMMDDHHMMSS.fff
    This is good for comparison but bad for math. Epoch seconds are
    good for both. That's why *I* use them. You can continue to use
    ISO mumble and have it work for you. I'm not breaking your code.

    There's also the issue that Perl code should (where practical) be
    portable by default. Perl tries to cover up operating system
    oddities. This is one oddity that can (and, I think, should) be
    covered up.

    Nat
  • Chaim Frenkel at Aug 25, 2000 at 9:50 pm
    "NT" == Nathan Torkington writes:
    NT> This is good for comparison but bad for math. Epoch seconds are
    NT> good for both. That's why *I* use them. You can continue to use
    NT> ISO mumble and have it work for you. I'm not breaking your code.

    NT> There's also the issue that Perl code should (where practical) be
    NT> portable by default. Perl tries to cover up operating system
    NT> oddities. This is one oddity that can (and, I think, should) be
    NT> covered up.

    I really don't care. As long as I can _easily_ convert it to the
    system native format.

    So are you proposing that perl carry/develop/borrow/steal its own
    date/time library?

    Because if you do pick an epoch, the native library may not be able to
    carry you far enough. So pick your poison, are we subject to the whims
    of the platform or should we stand on our own two feet?

    Strange thought just crossed my mind.

    Would having a time object that is understood by perl be sufficient?
    It would smell and taste like an integer but would otherwise be
    magical.

    <chaim>
    --
    Chaim Frenkel Nonlinear Knowledge, Inc.
    chaimf@pobox.com +1-718-236-0183
  • Chris Nandor at Aug 16, 2000 at 4:18 am

    At 22:07 -0600 2000.08.15, Nathan Torkington wrote:
    NOTICE: reply-to set to the -language-datetime list.

    Ted Ashton writes:
    Well then, why 1970? If we're defining our own, why buy into one
    which is scheduled to blow up in 2038? Why not at the very least
    start with Jan 1, 2K?
    This works, provided epoch seconds are stored in some form of big
    integers (either arbitrary precision, or 64-bit). The epoch change
    would then be fine by me. But epoch changes don't solve the 2038
    problem, Unix already tried that before the move to 32-bit integers
    (they moved the epoch from 1970 to 1971, I think, when their previous
    size of integer was about to run out of space, then when it ran out
    again next year they said "yeah, ok, wrong solution" :-).
    Yeah; if you change us Macs to 1970 instead of 1904, we actually run out of
    time two years earlier! No thanks ...

    --
    Chris Nandor | pudge@pobox.com | http://pudge.net/
    Andover.Net | chris.nandor@andover.net | http://slashcode.com/
  • Chris Nandor at Aug 17, 2000 at 10:05 pm
    Here are some comments from Matthias Neeracher, the MacPerl author, and a
    few comments from me.
    To: Chris Nandor <pudge@pobox.com>
    Subject: Re: Fwd: RFC 99 (v2) Standardize ALL Perl platforms on UNIX epoch
    Date: Wed, 16 Aug 2000 07:31:25 +0200
    From: Matthias Ulrich Neeracher <neeri@guest.iis.ee.ethz.ch>

    In message <p04320408b5bfc61cab94@[192.168.0.77]> you write:
    I am on the new perl6-language-datetime@perl.org mailing list. I am not
    sure whether I care if Mac OS uses Unix epoch or not, but I figure since
    Mac OS is the only one that differs
    Is it? I thought DOS/Windows uses 1900, but I don't know what Perl on these
    platforms does.
    What do you think?
    I can live with whatever epoch is chosen.
    Subject: RFC 99 (v2) Standardize ALL Perl platforms on UNIX epoch
    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).
    Note that this assumes that all systems on which Perl runs know what
    time zone they are in. This assumption may not universally hold.
    =head1 DESCRIPTION

    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.
    Personally, I find consistency between Perl internal calls and direct system
    calls more important, but I know that this is a minority position.
    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.
    Not sure I buy this sort of reasoning. What I'd rather see in the Perl
    standardization process is a systematic reference to standards (i.e., the
    current implementation of MacPerl tries to stay within the latitude granted
    by ISO C; it seems that the author is referring to POSIX.1 or UNIX 98, but
    he should do so explicitly).

    Also, at the very least, it should be stated that the value should have at
    least 32 significant bits, i.e., be an unsigned 32 bit integer.
    Or, if we're gonna not go along with the standard time_t, might as well
    make it 64.

    =head1 IMPLEMENTATION

    The C<time> core function must be changed to return the number of
    seconds since the UNIX epoch on ALL platforms.
    I don't think that this is all that is intended. surely, stat and lstat
    must be consistent with that, and doubtlessly other calls. The RFC should have
    an exhaustive list of Perl calls that are expected to conform to this.

    Matthias

    -----
    Matthias Neeracher <neeri@iis.ee.ethz.ch> http://www.iis.ee.ethz.ch/~neeri
    "These days, though, you have to be pretty technical before you can
    even aspire to crudeness." -- William Gibson, _Johnny Mnemonic_
    --
    Chris Nandor | pudge@pobox.com | http://pudge.net/
    Andover.Net | chris.nandor@andover.net | http://slashcode.com/
  • Russ Allbery at Aug 17, 2000 at 10:22 pm

    Chris Nandor writes:

    Here are some comments from Matthias Neeracher, the MacPerl author, and
    a few comments from me.
    Cool, thanks.
    Is it? I thought DOS/Windows uses 1900, but I don't know what Perl on
    these platforms does.
    My understanding is that the native epoch of DOS was 1980, but I don't
    know if Microsoft has since changed that from the Windows 3.1 days (which
    were the last time I used a Microsoft operating system for more than a few
    minutes needed to get to a terminal emulator and a Unix machine).
    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).
    Note that this assumes that all systems on which Perl runs know what
    time zone they are in. This assumption may not universally hold.
    This is a good point which is very much worth bearing in mind. It's not a
    problem on Unix systems, since Unix time is in UTC (well, a slightly weird
    UTC, but close enough for most purposes). This isn't the normal case on
    Windows (and possibly Mac; I don't know), where normally the system clock
    is kept in local time instead. This historically is due to Unix having
    generally better time zone handling than the personal computers of the
    time (back in the 1980s).

    If you keep the system clock in UTC, you *have* to understand time zones
    and get them right, up to and including daylight savings time, or the user
    will be confused. If you keep the system clock in local time, you can get
    away with knowing nothing about time zones and often with knowing nothing
    about daylight savings time and relying on the user to reset the computer
    clock like they would the clock on their microwave.

    It may not be *possible* to convert the internal clock of some systems to
    a Unix epoch; it may in fact not be possible to convert it to anything
    consistent at all because the actual value of the epoch may be completely
    unknown. I have no idea how to deal with that problem.
    Personally, I find consistency between Perl internal calls and direct
    system calls more important, but I know that this is a minority
    position.
    I'm rather sympathetic to this position personally, actually.
    Also, at the very least, it should be stated that the value should have
    at least 32 significant bits, i.e., be an unsigned 32 bit integer.
    Unix time currently uses a signed integer for reasons related to error
    handling on most platforms; unsigned time_t was tried as an experiment in
    the 1980s in BSD and reverted because it caused too much confusion.
    Or, if we're gonna not go along with the standard time_t, might as well
    make it 64.
    32 bits is clearly insufficient; I would support that.

    --
    Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
  • Alan Burlison at Aug 23, 2000 at 10:05 am

    Russ Allbery wrote:

    Or, if we're gonna not go along with the standard time_t, might as well
    make it 64.
    32 bits is clearly insufficient; I would support that.
    Be aware that perl5 already will support a 64-bit time_t if it is
    compiled as a 64 bit application. This is because time_t is defined as
    long, and on LP64 platforms (the majority of 64 bit platforms are I
    think), long becomes 64 bit when apps are compiled to be 64 bit:

    $ cat t.c
    #include <sys/types.h>
    int main() { printf("time_t is %d bits\n", sizeof(time_t) * 8); }
    $ cc -o t t.c
    $ file t
    t: ELF 32-bit MSB executable SPARC Version 1, dynamically
    linked, not stripped
    $ ./t
    time_t is 32 bits
    $ cc -o t t.c -xarch=v9
    $ file t
    t: ELF 64-bit MSB executable SPARCV9 Version 1, dynamically
    linked, not stripped
    $ ./t
    time_t is 64 bits

    --
    Alan Burlison
  • Chris Nandor at Aug 23, 2000 at 11:25 am

    At 11:05 +0100 2000.08.23, Alan Burlison wrote:
    Be aware that perl5 already will support a 64-bit time_t if it is
    compiled as a 64 bit application. This is because time_t is defined as
    long, and on LP64 platforms (the majority of 64 bit platforms are I
    think), long becomes 64 bit when apps are compiled to be 64 bit:
    Interesting. I still think we should have our own real 64-bit time,
    though, since not all platforms will be 64 bit (although by 2020 they may
    be), and perhaps not all of them will be LP64 (and I confess to not know
    what that stands for :).

    --
    Chris Nandor pudge@pobox.com http://pudge.net/
    Open Source Development Network pudge@osdn.com http://osdn.com/
  • Alan Burlison at Aug 23, 2000 at 2:02 pm

    Chris Nandor wrote:

    Interesting. I still think we should have our own real 64-bit time,
    though, since not all platforms will be 64 bit (although by 2020 they may
    be), and perhaps not all of them will be LP64 (and I confess to not know
    what that stands for :).
    Simple - LP64 = 'Longs and Pointers are 64 bit'. There are several
    other alternatives too, although most everyone seems to have settled on
    LP64. See the paper at
    http://www.unix-systems.org/version2/whatsnew/lp64_wp.html

    --
    Alan Burlison
    Solaris Kernel Development, Sun Microsystems

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupperl6-language-datetime @
categoriesperl
postedAug 16, '00 at 4:08a
activeAug 25, '00 at 9:50p
posts9
users5
websiteperl6.org

People

Translate

site design / logo © 2021 Grokbase