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: 12 Sep 2000
Mailing List: perl6-language-datetime@perl.org
Number: 99
Version: 3
Status: Developing

=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

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.

=head1 IMPLEMENTATION

A simplistic Perl 5 implementation of this can be found as Time::Unix
http://www.perl.com/CPAN/authors/id/N/NW/NWIGER/Time-Unix-1.02.tar.gz

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.

In addition, a C<systime> function should be added which provides access
to the native epoch/system time. For simplification, it might be best if
this C<systime> function remain the basis for other library-related
functions, such as C<stat>, C<lstat>, and so on, which typically rely on
native system time.

An alternative to C<systime>, proposed by Chaim Frenkel, is to have a
C<time> object which is magical yet walks and talks like a number (much
like the C<date> objects proposed in RFC 48). In the author's opinion,
either method is quite suitable (in fact I tend to like Chaim's idea a
lot).

=head1 CHANGES

Version 2:
1. Added extra implementation notes
2. Wrote a I<very> simple Perl 5 implementation

Version 1 of this RFC was entitled
"Maintain internal time in Modified Julian (not epoch)".

=head1 REFERENCES

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

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

Search Discussions

  • Michael G Schwern at Sep 13, 2000 at 9:34 am

    On Wed, Sep 13, 2000 at 07:10:30AM -0000, Perl6 RFC Librarian wrote:
    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).
    Color me obvious, but could you discuss some of the practical
    situations where this becomes a problem? My gut says you're very
    right, but the only one I could think of is that of two Perl programs
    on two different OS's with two different Epochs storing time() in a
    database and sharing the info. (At which point the DBAs in the
    audience will say you should have used an SQL DATETIME type instead of
    an INTEGER.)

    And if we're going to standardize on something, let's squeeze as much
    out of this as possible. signed 64 bit integer and microseconds. (I
    think that's another RFC)

    --

    Michael G Schwern http://www.pobox.com/~schwern/ schwern@pobox.com
    Just Another Stupid Consultant Perl6 Kwalitee Ashuranse
    But why? It's such a well designed cesspool of C++ code. Why wouldn't
    you want to hack mozilla?
    -- Ziggy
  • Chris Nandor at Sep 13, 2000 at 6:13 pm

    At 5:34 -0400 2000.09.13, Michael G Schwern wrote:
    On Wed, Sep 13, 2000 at 07:10:30AM -0000, Perl6 RFC Librarian wrote:
    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).
    Color me obvious, but could you discuss some of the practical
    situations where this becomes a problem? My gut says you're very
    right, but the only one I could think of is that of two Perl programs
    on two different OS's with two different Epochs storing time() in a
    database and sharing the info. (At which point the DBAs in the
    audience will say you should have used an SQL DATETIME type instead of
    an INTEGER.)
    It is rarely a problem, but I have run into it, where people want to store
    time() in a file and then use it on other platforms (Mac OS).

    And if we're going to standardize on something, let's squeeze as much
    out of this as possible. signed 64 bit integer and microseconds. (I
    think that's another RFC)
    Yeah, at least 64 bits. Microseconds, well, I don't really know much about
    such things, nor do I care.

    I don't see any problem with implementing this in the core, as long as the
    current timezone is known (which could be a problem). And then we would
    need to be able to provide converstions to and from this "Perl" epoch and
    the system epoch. I've already started Time::Epoch to facilitate this.

    #!/usr/bin/perl -wl
    use Time::Epoch;
    my $perlsec = 966770660; # Sun Aug 20 07:24:21 2000 on my Mac OS
    my $epochsec = perl2epoch($perlsec, 'macos', '-0400');
    my $perlsec2 = epoch2perl($epochsec, 'macos', '-0400');

    print $perlsec;
    print $perlsec2;
    print $epochsec;
    # correct time on Unix:
    print scalar localtime $perlsec;
    # correct time on Mac OS (-0400):
    print scalar localtime $epochsec;

    I should put it up on CPAN. If anyone wants it, let me know.

    --
    Chris Nandor pudge@pobox.com http://pudge.net/
    Open Source Development Network pudge@osdn.com http://osdn.com/
  • Andy Dougherty at Sep 13, 2000 at 6:29 pm

    On Wed, 13 Sep 2000, Michael G Schwern wrote:

    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).
    Color me obvious, but could you discuss some of the practical
    situations where this becomes a problem?
    There are potential problems either way.

    1. (Perl5 way): If you store the time from within a perl program and
    then read it with a perl program on another OS, then you might have a
    problem.

    2. (RFC 99 way): If you store the time from within a perl program and
    then read it with a C program on the SAME OS, then you might have a
    problem.

    In my work, I encounter both situations. I work on the same data with
    different languages. I also move that same data among different systems.
    (At which point the DBAs in the
    audience will say you should have used an SQL DATETIME type instead of
    an INTEGER.)
    Exactly. (Or some suitable generalization if your "database" isn't
    really a Database, but just a plain ol' file.)

    Since either way can produce problems, I think we ought to stick with
    the way that's the least work for perl -- namely doing nothing!

    In my humble opinion, I think perl's time() ought to just call the C
    library's time() function and not waste time mucking with the return
    value. Instead, if the time is to be stored externally for later use by
    another program, the programmer should be responsible for converting the
    time into a suitably useful and portable format. Any unilateral choice
    made by Perl6 in that regard isn't going to be of any help unless everyone
    else (Java, Python, C, etc.) follows along.

    --
    Andy Dougherty doughera@lafayette.edu
    Dept. of Physics
    Lafayette College, Easton PA 18042
  • Chris Nandor at Sep 13, 2000 at 6:42 pm

    At 14:30 -0400 2000.09.13, Andy Dougherty wrote:
    2. (RFC 99 way): If you store the time from within a perl program and
    then read it with a C program on the SAME OS, then you might have a
    problem.
    That is what Time::Epoch should address, I hope.

    If we standardize on the Unix epoch (although possibly with 64 bits), this
    won't be an issue for the overwhelming majority of users.

    In my humble opinion, I think perl's time() ought to just call the C
    library's time() function and not waste time mucking with the return
    value.
    I am not opposed to this. If we stick with it, then I will make
    Time::Epoch convert between Mac OS and Unix time, and any other epoch we
    deem necessary.

    --
    Chris Nandor pudge@pobox.com http://pudge.net/
    Open Source Development Network pudge@osdn.com http://osdn.com/
  • Andy Dougherty at Sep 13, 2000 at 8:03 pm

    On Wed, 13 Sep 2000, Chris Nandor wrote:
    At 14:30 -0400 2000.09.13, Andy Dougherty wrote:
    2. (RFC 99 way): If you store the time from within a perl program and
    then read it with a C program on the SAME OS, then you might have a
    problem.
    That is what Time::Epoch should address, I hope.
    Well sure, if the programmer is going to be responsible enough to use
    Time::Epoch[*] (or any other suitable way of storing time information)
    then either the perl5 way or the RFC99 way can be used just fine in
    principle.

    It goes both ways. No matter what perl6 does, there are real situations
    where problems could arise. And, of course, there are workarounds to most
    of those problems.[**]

    The question is simply one of defaults, and I think the perl5 way is
    better. Within a running program, it seems to make more sense to me to
    stay consistent with the underlying system library call. After all, you
    might access that library call in a variety of indirect ways, such as
    stat() and through XS extensions.

    When storing data to disk, of course you have to consider how that data
    will subsequently used. That's a good time to think about epochs and the
    whole broader question of appropriate date/time storage. But if you're
    storing useful data to disk, you're probably storing more than just the
    time. For every other piece of data you store, you still have to consider
    how you want it stored. Standardizing on the epoch for just one piece of
    data, namely the time, just doesn't seem to me to be all that useful.
    If we standardize on the Unix epoch (although possibly with 64 bits), this
    won't be an issue for the overwhelming majority of users.
    Are you sure? Won't this affect Windows as well as Mac users? There are
    an awful lot of Windows users.

    --
    Andy Dougherty doughera@lafayette.edu
    Dept. of Physics
    Lafayette College, Easton PA 18042

    [*] I'm guessing here, since I've never seen Time::Epoch described and
    can't find it in the archives for this list.

    [**] Aren't there systems which keep local time and for which the
    conversion to UTC simply can't be figured out? Of course these issues are
    likely to less-frequently encountered on such systems, so I suppose it
    doesn't matter too much either way.
  • Chris Nandor at Sep 13, 2000 at 8:17 pm

    At 16:04 -0400 2000.09.13, Andy Dougherty wrote:
    If we standardize on the Unix epoch (although possibly with 64 bits), this
    won't be an issue for the overwhelming majority of users.
    Are you sure? Won't this affect Windows as well as Mac users? There are
    an awful lot of Windows users.
    I don't think so; AFAIK, the epoch is the same in Windows as in Unix.

    --
    Chris Nandor pudge@pobox.com http://pudge.net/
    Open Source Development Network pudge@osdn.com http://osdn.com/
  • Chaim Frenkel at Sep 14, 2000 at 4:12 am
    "AD" == Andy Dougherty writes:
    AD> In my humble opinion, I think perl's time() ought to just call the C
    AD> library's time() function and not waste time mucking with the return
    AD> value. Instead, if the time is to be stored externally for later use by
    AD> another program, the programmer should be responsible for converting the
    AD> time into a suitably useful and portable format. Any unilateral choice
    AD> made by Perl6 in that regard isn't going to be of any help unless everyone
    AD> else (Java, Python, C, etc.) follows along.

    Possibly a few functions to make it easy.

    $Perl::EpochOffset

    0 on a unix box
    966770660 on a Mac (Lifted from pudge's previous email)
    etc.

    Then on output. print time()-$Perl::EpochOffset;

    One other that might be useful is have strftime() (or something
    similar) built-in without having to use POSIX; and the default should
    be YYYYMMDDHHMMSS.fffffff, (the ISO format)

    I personally prefer to pass around the string representation, more
    that perl and unix systems need to handle datetime. (And I find it
    easier to read the ISO version than a time in seconds)

    <chaim>
    --
    Chaim Frenkel Nonlinear Knowledge, Inc.
    chaimf@pobox.com +1-718-236-0183
  • Russ Allbery at Sep 14, 2000 at 4:54 am

    Chaim Frenkel writes:

    One other that might be useful is have strftime() (or something similar)
    built-in without having to use POSIX; and the default should be
    YYYYMMDDHHMMSS.fffffff, (the ISO format)
    The more commonly-used ISO format is the extended format rather than the
    basic one:

    YYYY-MM-DDTHH:MM:SS+ZZZZ

    (and yes, the T is part of the format). More commonly, people use the ISO
    extended date format and the ISO extended time format separately with a
    space between them and the time zone also separated out:

    YYYY-MM-DD HH:MM:SS +ZZZZ
    I personally prefer to pass around the string representation, more
    that perl and unix systems need to handle datetime. (And I find it
    easier to read the ISO version than a time in seconds)
    I agree. The ISO format is better if you need to write out a date to a
    file that you're reading later and you don't need absolutely maximum
    speed, particularly if you have good tools to parse it and turn it back
    into a native format again.

    --
    Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
  • Chris Nandor at Sep 14, 2000 at 11:12 am

    At 0:12 -0400 2000.09.14, Chaim Frenkel wrote:
    Possibly a few functions to make it easy.

    $Perl::EpochOffset

    0 on a unix box
    966770660 on a Mac (Lifted from pudge's previous email)
    etc.

    Then on output. print time()-$Perl::EpochOffset;
    No, that won't really work. When my offset from GMT changes for daylight
    savings time, it will break. The point of having a module is that epoch
    conversions are more complicated than that. For example, Mac OS epoch
    begins at Jan 1 1904 00:00:00 _local time_. That is why the timezone
    offset from GMT was passed to the Time::Epoch functions.

    This is probably why I don't think too many Mac people would mind if the
    epoch in MacPerl changes; it is unreliable for keeping persistently on Mac
    OS anyway. That doesn't mean it is never useful, but you can't save the
    epoch to disk without the GMT offset and have it be useful, unless you know
    you'll never change time zones. In the U.S., that means living in one of
    the few places that ignores DST, and that you aren't using a laptop that
    you travel to other places with, and that you aren't planning on moving ...
    in other words, it is safer to use a more unambiguous representation for
    storing the time.

    Also, you might want to convert between other epochs; what if you get an
    epoch value FROM Mac OS on a Unix box, and want to convert it?

    So again, are there any other platforms that do not have as the beginning
    of their epoch 1970-01-01 00:00:00 +0000? I think we need to list all of
    them and note which ones can be changed in the manner proposed, and which
    ones can't.

    I personally prefer to pass around the string representation, more
    that perl and unix systems need to handle datetime. (And I find it
    easier to read the ISO version than a time in seconds)
    I think it would be reasonable to have a quick-and-easy way to get the time
    in the extended ISO format, as Russ noted it.

    --
    Chris Nandor pudge@pobox.com http://pudge.net/
    Open Source Development Network pudge@osdn.com http://osdn.com/
  • Chaim Frenkel at Sep 14, 2000 at 9:47 pm
    "CN" == Chris Nandor writes:
    CN> No, that won't really work. When my offset from GMT changes for daylight
    CN> savings time, it will break. The point of having a module is that epoch
    CN> conversions are more complicated than that. For example, Mac OS epoch
    CN> begins at Jan 1 1904 00:00:00 _local time_. That is why the timezone
    CN> offset from GMT was passed to the Time::Epoch functions.

    I'm confused.

    How do you expect the program to know the timezone if the OS doesn't?
    And if the program knows it and can track it, then we can hand off the
    responsibility to Perl. Then the epoch would 'vary' according to whatever
    nonsense is necessary.

    But if the values wander so badly, what does the OS use? If perl has to
    convert away, then it can easily use Unix epoch.

    CN> Also, you might want to convert between other epochs; what if you get an
    CN> epoch value FROM Mac OS on a Unix box, and want to convert it?

    That's a different problem than we are trying to solve. This is a wider
    problem then a fixed epoch for perl. Let's turn this around. What if
    we are on a platform that doesn't use perl's epoch and we need to write
    a value to a file?

    I think I've just gotten very confused.
    <chaim>
    --
    Chaim Frenkel Nonlinear Knowledge, Inc.
    chaimf@pobox.com +1-718-236-0183
  • Chris Nandor at Sep 14, 2000 at 11:20 pm

    At 17:47 -0400 2000.09.14, Chaim Frenkel wrote:
    "CN" == Chris Nandor <pudge@pobox.com> writes:
    CN> No, that won't really work. When my offset from GMT changes for daylight
    CN> savings time, it will break. The point of having a module is that epoch
    CN> conversions are more complicated than that. For example, Mac OS epoch
    CN> begins at Jan 1 1904 00:00:00 _local time_. That is why the timezone
    CN> offset from GMT was passed to the Time::Epoch functions.

    I'm confused.

    How do you expect the program to know the timezone if the OS doesn't?
    I am not sure what you mean by "the program." If you mean perl, well, perl
    often doesn't. Figuring out the correct time zones is sometimes quite
    hard. And yes, sometimes the OS is completely lacking in knowledge of a
    time zone. If you'll note, the Time::Epoch example asked that the time
    zone differential be one of the arguments, because we don't want to rely on
    guessing (but we fall back to guessing if none is supplied).

    Assuming the OS does know, and perl can find out from the OS, then perhaps
    a variable would work. But I, for the most part, despise the idea of
    adding more global variables to Perl. I would much rather call a simple
    function.

    And if the program knows it and can track it, then we can hand off the
    responsibility to Perl.
    My program knows the timezone difference because I hardcoded it in. :)

    CN> Also, you might want to convert between other epochs; what if you get an
    CN> epoch value FROM Mac OS on a Unix box, and want to convert it?

    That's a different problem than we are trying to solve.
    I don't think so. What we are trying to solve is the problem of different
    system epochs.

    This is a wider
    problem then a fixed epoch for perl. Let's turn this around. What if
    we are on a platform that doesn't use perl's epoch and we need to write
    a value to a file?
    Yes. What if? That's what we're addressing. Right now, you need to use
    something like Time::Epoch to do a conversion, or you use a non-ambiguous
    representation, such as you get with Date::Manip (which, BTW, I believe is
    broken in respect to MacPerl's epoch; that is, I think I needed to convert
    to Unix epoch before doing something with it).

    --
    Chris Nandor pudge@pobox.com http://pudge.net/
    Open Source Development Network pudge@osdn.com http://osdn.com/
  • Chaim Frenkel at Sep 15, 2000 at 2:20 am

    "CN" == Chris Nandor writes:
    This is a wider
    problem then a fixed epoch for perl. Let's turn this around. What if
    we are on a platform that doesn't use perl's epoch and we need to write
    a value to a file?
    CN> Yes. What if? That's what we're addressing. Right now, you need to use
    CN> something like Time::Epoch to do a conversion, or you use a non-ambiguous
    CN> representation, such as you get with Date::Manip (which, BTW, I believe is
    CN> broken in respect to MacPerl's epoch; that is, I think I needed to convert
    CN> to Unix epoch before doing something with it).

    You misundertood me. You have to know several different facts. The
    current epoch, the machine epoch, the epoch that the file requires.

    I really don't see that we need more than what is the difference between
    the timestamp returned from the syscalls, and the unix (or whatever)
    epoch.

    If you want to adjust for timezones just calculate the constant. Which
    since you are giving it in HHMM format you might as well just calculate
    directly.

    So what am I missing.

    <chaim>
    --
    Chaim Frenkel Nonlinear Knowledge, Inc.
    chaimf@pobox.com +1-718-236-0183
  • Chris Nandor at Sep 15, 2000 at 2:36 am

    At 22:19 -0400 2000.09.14, Chaim Frenkel wrote:
    If you want to adjust for timezones just calculate the constant. Which
    since you are giving it in HHMM format you might as well just calculate
    directly.

    So what am I missing.
    Beats me. I am not sure whether or not you have a point, and if so, what
    it is. I am not trying to be difficult. Maybe I am just tired, but I am
    not sure what you are trying to say.

    --
    Chris Nandor pudge@pobox.com http://pudge.net/
    Open Source Development Network pudge@osdn.com http://osdn.com/
  • Chris Nandor at Sep 15, 2000 at 1:56 pm

    At 9:17 -0400 2000.09.15, Chaim Frenkel wrote:
    "CN" == Chris Nandor <pudge@pobox.com> writes:
    CN> At 22:19 -0400 2000.09.14, Chaim Frenkel wrote:
    If you want to adjust for timezones just calculate the constant. Which
    since you are giving it in HHMM format you might as well just calculate
    directly.

    So what am I missing.
    CN> Beats me. I am not sure whether or not you have a point, and if so, what
    CN> it is. I am not trying to be difficult. Maybe I am just tired, but I am
    CN> not sure what you are trying to say.

    I'm not sure either. But my understanding still seems to be that the
    problem is a simple adjustment issue.

    my_time_in_local_epoc
    + current_os_epoch_offset
    - timezone_ofset_in_seconds
    = time_in_unix_epoch_seconds
    But again, I don't know what you are trying to say. Are you saying we
    should have some global "constant"? If so, you still have problems:

    * We do not know if it will always be this simple for every platform
    * You might need to convert from an epoch other than your native one,
    whether it
    is a different time zone, or a different epoch entirely; with a function, you
    can easily take care of these problems
    * Global variables suck

    So the only piece that is needed is the current os epoch offset and
    perhaps the timezone offset. But I think having perl look at TZ (or a
    PERL6TZ) on those platforms that don't handle timezones correctly
    seems like a minor tweak to the syscall wrapper functions.
    TZ is unreliable. We should never offer a solution that is going to rely
    on TZ without knowing the exact details. We need to identify platforms
    that have problems and what neeeds to be done with them.

    And we can avoid breakage with current scripts.
    You can only avoid breakage with current scripts if you make no changes to
    the current facilities (which is what Andy proposed). My proposal of a
    separate module for handing epoch differentials will work pretty much the
    same whether we change time() to return native or Perl epoch.

    No TZ, no adjustment
    current code works properly. TZ set, perl will do an adjustment.
    What adjustment? You were not before talking about doing any adjustment,
    were you? Maybe you could state exactly what you propose, because I don't
    know what it is.

    --
    Chris Nandor pudge@pobox.com http://pudge.net/
    Open Source Development Network pudge@osdn.com http://osdn.com/
  • Andy Dougherty at Sep 15, 2000 at 3:57 pm

    On Fri, 15 Sep 2000, Chris Nandor wrote:

    You can only avoid breakage with current scripts if you make no changes to
    the current facilities (which is what Andy proposed).
    Well I have to admit that I was unaware that on Mac and VMS (without the
    wizardry in vms/vms.c) the value returned by time() could jump behind your
    back if you were running when DST kicked in or out. If it were just
    different absolute epochs, I would tend to oppose the proposal (and
    recognize that I am probably in the minority and hence would gracefully
    yield anyway.) But this OS "feature" sounds to me like something that
    Perl should hide from the user. So, Yes, I'm tending to think perl6
    probably ought to muck with epochs if possible.

    [Aside: Does this mean that make(1) is useless for one hour after
    standard time resumes?]

    --
    Andy Dougherty doughera@lafayette.edu
    Dept. of Physics
    Lafayette College, Easton PA 18042
  • Bart Lateur at Sep 15, 2000 at 5:25 pm

    On Fri, 15 Sep 2000 11:58:08 -0400 (EDT), Andy Dougherty wrote:
    [Aside: Does this mean that make(1) is useless for one hour after
    standard time resumes?]
    That'll teach you. You shouldn't be programming in the middle of the
    night.

    --
    Bart.
  • Chaim Frenkel at Sep 15, 2000 at 7:56 pm

    "CN" == Chris Nandor writes:
    my_time_in_local_epoc
    + current_os_epoch_offset
    - timezone_ofset_in_seconds
    = time_in_unix_epoch_seconds
    CN> But again, I don't know what you are trying to say. Are you saying we
    CN> should have some global "constant"? If so, you still have problems:

    Sure, we have plenty of global constants. It could either be an UPPERCASE
    or something in the Perl:: namespace.

    CN> * We do not know if it will always be this simple for every platform

    Hard to see how the three variables wouldn't cover the spectrum.

    CN> * You might need to convert from an epoch other than your native
    CN> one, whether it is a different time zone, or a different epoch
    CN> entirely; with a function, you can easily take care of these
    CN> problems * Global variables suck

    That is beyond the scope of this problem. How to get a machine specific
    integral epoch seconds to a unix (or other) epoch seconds.

    This new module to cover your feature would require that it know every
    known epoch and timesystem (or at least the useful ones.) Something
    this domain knowledgable shouldn't be in CORE.

    CN> TZ is unreliable. We should never offer a solution that is going to rely
    CN> on TZ without knowing the exact details. We need to identify platforms
    CN> that have problems and what neeeds to be done with them.

    In what way is it unreliable? If the user/sysadmin sets it wrong, they
    will learn adjust. If you mean that people play with this to get some
    effects, then we should have a PERL6TZ that is the user/sysadmin's
    method of telling perl how the sysadmin has set the machines
    clock.

    If you don't like an envar, then something in Config.pm or its replacement
    that is adjusted upon installation.

    One other possiblity, if Perl could determine the epoch by examination.

    $unixepoch = mktime( "1970...");
    $machinepoch= mktime( "1970...");

    then none of this is necessary.

    CN> You can only avoid breakage with current scripts if you make no changes to
    CN> the current facilities (which is what Andy proposed). My proposal of a
    CN> separate module for handing epoch differentials will work pretty much the
    CN> same whether we change time() to return native or Perl epoch.

    I'm on the side of no change. Just enough that a user can determine how
    to offset the return from time, to pass to other data sinks.
    No TZ, no adjustment
    current code works properly. TZ set, perl will do an adjustment.
    CN> What adjustment? You were not before talking about doing any adjustment,
    CN> were you? Maybe you could state exactly what you propose, because I don't
    CN> know what it is.

    Disregard this. I was indicating that _IF_ p6 would honor a TZ variable
    the lack of a TZ variable could leave the results unchanged for old
    scripts. Just a way of maintaining backward compatiblity.

    <chaim>
    --
    Chaim Frenkel Nonlinear Knowledge, Inc.
    chaimf@pobox.com +1-718-236-0183
  • Chris Nandor at Sep 15, 2000 at 8:14 pm

    At 15:55 -0400 2000.09.15, Chaim Frenkel wrote:
    CN> * We do not know if it will always be this simple for every platform

    Hard to see how the three variables wouldn't cover the spectrum.
    Very hard to see, until we know what the disparate platforms might require. :)

    CN> * You might need to convert from an epoch other than your native
    CN> one, whether it is a different time zone, or a different epoch
    CN> entirely; with a function, you can easily take care of these
    CN> problems * Global variables suck

    That is beyond the scope of this problem.
    Depending on the solution. If we keep the situation as it is now, that
    time() is always system-dependent, then it is very much part of the scope
    of this problem, because we need to have ways for people to convert to and
    from other epochs. If we standardize on an epoch, then perhaps it isn't
    part of the problem.

    This new module to cover your feature would require that it know every
    known epoch and timesystem (or at least the useful ones.) Something
    this domain knowledgable shouldn't be in CORE.
    Why? File::Spec is in the core. So are multitudinous ExtUtils::MM_* modules.

    If you don't like an envar, then something in Config.pm or its replacement
    that is adjusted upon installation.
    Which is even more unreliable.

    One other possiblity, if Perl could determine the epoch by examination.

    $unixepoch = mktime( "1970...");
    $machinepoch= mktime( "1970...");
    Huh?

    CN> You can only avoid breakage with current scripts if you make no changes to
    CN> the current facilities (which is what Andy proposed). My proposal of a
    CN> separate module for handing epoch differentials will work pretty much the
    CN> same whether we change time() to return native or Perl epoch.

    I'm on the side of no change. Just enough that a user can determine how
    to offset the return from time, to pass to other data sinks.
    If you want no change, then what are you offset from? If time() remains
    system-dependent, then we have nothing against which to offset it.

    --
    Chris Nandor pudge@pobox.com http://pudge.net/
    Open Source Development Network pudge@osdn.com http://osdn.com/
  • Chaim Frenkel at Sep 15, 2000 at 9:11 pm

    "CN" == Chris Nandor writes:
    This new module to cover your feature would require that it know every
    known epoch and timesystem (or at least the useful ones.) Something
    this domain knowledgable shouldn't be in CORE.
    CN> Why? File::Spec is in the core. So are multitudinous
    CN> ExtUtils::MM_* modules.

    Covers the platforms that have perl ports. Your problem requires solutions
    for platforms that don't have a perl port. (yet :-)
    If you don't like an envar, then something in Config.pm or its replacement
    that is adjusted upon installation.
    CN> Which is even more unreliable.

    Come on now. Perl is only as reliable as its installation. Consider copying
    a Config.pm from one machine to another.
    One other possiblity, if Perl could determine the epoch by examination.

    $unixepoch = mktime( "1970...");
    $machinepoch= mktime( "1970...");
    CN> Huh?

    Oops. The value that mktime for the unix epoch is the offset needed.

    $unixepoch = mktime( ..., 1970 );
    @machinepoch = localtime(0);

    Some combination of mktime, localtime(0), will yield how much the epoch
    is shifted.
    I'm on the side of no change. Just enough that a user can determine how
    to offset the return from time, to pass to other data sinks.
    CN> If you want no change, then what are you offset from? If time() remains
    CN> system-dependent, then we have nothing against which to offset it.

    Just a function/variable that would contain the offset from machine/os
    system epoch to unix (or universal) epoch.

    <chaim>
    --
    Chaim Frenkel Nonlinear Knowledge, Inc.
    chaimf@pobox.com +1-718-236-0183
  • Chris Nandor at Sep 15, 2000 at 9:32 pm

    At 17:11 -0400 2000.09.15, Chaim Frenkel wrote:
    "CN" == Chris Nandor <pudge@pobox.com> writes:
    This new module to cover your feature would require that it know every
    known epoch and timesystem (or at least the useful ones.) Something
    this domain knowledgable shouldn't be in CORE.
    CN> Why? File::Spec is in the core. So are multitudinous
    CN> ExtUtils::MM_* modules.

    Covers the platforms that have perl ports. Your problem requires solutions
    for platforms that don't have a perl port. (yet :-)
    No, you misunderstabd. I am saying that we are not sure that we have the
    all the platforms covered that DO have perl ports. Only Mac and VMS and
    Unix users have spoken up, that I know of.

    If you don't like an envar, then something in Config.pm or its replacement
    that is adjusted upon installation.
    CN> Which is even more unreliable.

    Come on now. Perl is only as reliable as its installation. Consider copying
    a Config.pm from one machine to another.
    I don't think you understand ... if you use $ENV{TZ}, at least it can be
    changed for each user, for when you change time zones, DST, etc. For
    Config.pm, you have to edit a global value. Ick.

    I'm on the side of no change. Just enough that a user can determine how
    to offset the return from time, to pass to other data sinks.
    CN> If you want no change, then what are you offset from? If time() remains
    CN> system-dependent, then we have nothing against which to offset it.

    Just a function/variable that would contain the offset from machine/os
    system epoch to unix (or universal) epoch.
    But there is no universal epoch. And what makes Unix special?

    --
    Chris Nandor pudge@pobox.com http://pudge.net/
    Open Source Development Network pudge@osdn.com http://osdn.com/
  • Chaim Frenkel at Sep 18, 2000 at 3:22 pm
    "CN" == Chris Nandor writes:
    CN> Why? File::Spec is in the core. So are multitudinous
    CN> ExtUtils::MM_* modules.
    Covers the platforms that have perl ports. Your problem requires solutions
    for platforms that don't have a perl port. (yet :-)
    CN> No, you misunderstabd. I am saying that we are not sure that we have the
    CN> all the platforms covered that DO have perl ports. Only Mac and VMS and
    CN> Unix users have spoken up, that I know of.

    :-) No, you misunderstood. Your solution requires knowledge of non-port
    target platforms.
    Come on now. Perl is only as reliable as its installation. Consider copying
    a Config.pm from one machine to another.
    CN> I don't think you understand ... if you use $ENV{TZ}, at least it can be
    CN> changed for each user, for when you change time zones, DST, etc. For
    CN> Config.pm, you have to edit a global value. Ick.

    But the OS's idea of the epoch is global!
    Just a function/variable that would contain the offset from machine/os
    system epoch to unix (or universal) epoch.
    CN> But there is no universal epoch. And what makes Unix special?

    The universal epoch for perl. Unix is not. It is simply one that is
    well known. I really don't care what the offset is. We could even
    have multiple. All that is required that a perl program be able
    to determine portably what the difference between the syscall idea
    of time and some 'universal' perl epoch.

    Then all the programs would need to be able to translate from any
    OS to any other OS would be the offsets between any system and
    the perl epoch.

    Perl would not have to maintain this table it would not have to go
    out in CORE, one less thing to be maintained.

    <chaim>
    --
    Chaim Frenkel Nonlinear Knowledge, Inc.
    chaimf@pobox.com +1-718-236-0183
  • Chris Nandor at Sep 19, 2000 at 11:56 pm

    At 11:21 -0400 2000.09.18, Chaim Frenkel wrote:
    CN> I don't think you understand ... if you use $ENV{TZ}, at least it can be
    CN> changed for each user, for when you change time zones, DST, etc. For
    CN> Config.pm, you have to edit a global value. Ick.

    But the OS's idea of the epoch is global!
    No, it isn't! On Mac OS, I can change my epoch by changing my time zone.
    If it is harcoded into Config.pm, I am fucked.

    Just a function/variable that would contain the offset from machine/os
    system epoch to unix (or universal) epoch.
    CN> But there is no universal epoch. And what makes Unix special?

    The universal epoch for perl.
    But by saying we should not change the current idea of epoch, you're saying
    we shouldn't have a universal perl epoch, unless you have an idea for how
    it would be implemented that you haven't shared (aside from the offset,
    because that simply brings us back to "offset from what?").

    have multiple. All that is required that a perl program be able
    to determine portably what the difference between the syscall idea
    of time and some 'universal' perl epoch.
    But there is none of the latter.

    --
    Chris Nandor pudge@pobox.com http://pudge.net/
    Open Source Development Network pudge@osdn.com http://osdn.com/
  • Bart Lateur at Sep 20, 2000 at 11:22 am

    On Mon, 18 Sep 2000 11:42:50 -0400, Chris Nandor wrote:

    But the OS's idea of the epoch is global!
    No, it isn't! On Mac OS, I can change my epoch by changing my time zone.
    If it is harcoded into Config.pm, I am fucked.
    This is bad. That system is broken. ;-) I guess that it's the same
    situation on MS-DOS, since there the hardware clock is usually set to
    local time. It could even happen on Win32?!?

    This surely was a bad design decision from the hardware guys. Very
    shortsighted.

    Anyway, I think that on such systems, globaltime() is derived from
    localtime(), not the reverse.

    --
    Bart.
  • Chris Nandor at Sep 20, 2000 at 11:42 am

    At 13:23 +0200 2000.09.20, Bart Lateur wrote:
    This surely was a bad design decision from the hardware guys. Very
    shortsighted.
    I don't know if it has anything to do with the hardware clock. It has to
    do with what the Mac OS API returns for seconds since epoch. The
    difference from GMT, or the difference from anything, cannot be hardcoded,
    because it is dynamic, depending on what timezone you are in at the moment.

    --
    Chris Nandor pudge@pobox.com http://pudge.net/
    Open Source Development Network pudge@osdn.com http://osdn.com/
  • Chaim Frenkel at Sep 24, 2000 at 7:54 pm
    "CN" == Chris Nandor writes:
    CN> At 13:23 +0200 2000.09.20, Bart Lateur wrote:
    This surely was a bad design decision from the hardware guys. Very
    shortsighted.
    CN> I don't know if it has anything to do with the hardware clock. It has to
    CN> do with what the Mac OS API returns for seconds since epoch. The
    CN> difference from GMT, or the difference from anything, cannot be hardcoded,
    CN> because it is dynamic, depending on what timezone you are in at the moment.

    What sets the timezone? And can it be different for different applications
    running at the same time?

    How does an application query what the current timezone or zone offset is?

    <chaim>
    --
    Chaim Frenkel Nonlinear Knowledge, Inc.
    chaimf@pobox.com +1-718-236-0183
  • Russ Allbery at Sep 20, 2000 at 8:03 pm

    Bart Lateur writes:

    This is bad. That system is broken. ;-) I guess that it's the same
    situation on MS-DOS, since there the hardware clock is usually set to
    local time. It could even happen on Win32?!?
    This surely was a bad design decision from the hardware guys. Very
    shortsighted.
    It's not a hardware problem; the hardware clock just keeps a time. It has
    no concept of time zones. It's a software problem; back when DOS was a
    dead-simple operating system, Microsoft decided to interpret the time as
    local time, probably because that was simpler and getting time zones right
    is hard (and a larger problem than DOS was really prepared to handle,
    since programs mostly bypassed it and programs mostly want local time).

    Of course, it then gets into the backward compatibility feature matrix and
    never goes away.

    Note that Linux gets this right, making it obvious that it's not a
    hardware problem. (Actually, Linux gives you the option of interpreting
    the hardware clock as UTC or as local time, so that you can do the latter
    for compatibility with Windows, but if you do that it adjusts the hardware
    clock with your time zone information before setting the system clock in
    the kernel at boot.)

    --
    Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
  • Bart Lateur at Sep 20, 2000 at 8:31 pm

    On 20 Sep 2000 13:03:22 -0700, Russ Allbery wrote:
    It's not a hardware problem; the hardware clock just keeps a time. It has
    no concept of time zones.
    I thought later on that I wrote this the wrong way. What I ment was: the
    guys who did the interface to the hardware.
    It's a software problem; back when DOS was a
    dead-simple operating system, Microsoft decided to interpret the time as
    local time, probably because that was simpler and getting time zones right
    is hard
    Which is precisely the shortsighted and wrong design decision I was
    talking about.

    From a pure hardware point of view, letting a clock run on and on
    without regard of timezone and daylight saving time, is a lot simpler,
    than updating the hardware clock every time DST goes into or out of
    effect.

    So actually, these guys have, in their childish enthousiasm, chosen the
    hard way.

    It looks to me like Windows 2000 still keeps localtime in the hardware
    clock. Can you believe that?

    --
    Bart.
  • Bart Lateur at Sep 15, 2000 at 7:39 am

    On Thu, 14 Sep 2000 19:19:34 -0400, Chris Nandor wrote:
    And yes, sometimes the OS is completely lacking in knowledge of a
    time zone.
    This problem isn't new. Currently, Perl must know the timezone to be
    able to correctly generate gmtime() and localtime().

    --
    Bart.
  • Russ Allbery at Sep 13, 2000 at 9:22 pm

    Michael G Schwern writes:

    And if we're going to standardize on something, let's squeeze as much
    out of this as possible. signed 64 bit integer and microseconds. (I
    think that's another RFC)
    I think it should be specified that the return value is seconds since Unix
    epoch and the storage size be left unspecified, from the language
    perspective. On those platforms that support it, using 64 bits is
    obviously a good idea.

    --
    Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
  • Bart Lateur at Sep 14, 2000 at 6:55 pm

    On 13 Sep 2000 14:22:30 -0700, Russ Allbery wrote:
    I think it should be specified that the return value is seconds since Unix
    epoch and the storage size be left unspecified, from the language
    perspective. On those platforms that support it, using 64 bits is
    obviously a good idea.
    64 bits is a good idea on any platform. The processors can handle it,
    even if they're not 64 bit processors. One problem is: can your C
    compiler handle it?

    Now, on those platforms without 64 bit support, a double float has a lot
    more mantissa bits than 32, typically 50-something (on a total of 64
    bits). This means that all integers with up to more than 50 significant
    bits can exactly be represented. That would be a lot better than the
    current situation of 32 bits.

    --
    Bart.
  • Russ Allbery at Sep 14, 2000 at 10:10 pm

    Bart Lateur writes:

    Now, on those platforms without 64 bit support, a double float has a lot
    more mantissa bits than 32, typically 50-something (on a total of 64
    bits). This means that all integers with up to more than 50 significant
    bits can exactly be represented. That would be a lot better than the
    current situation of 32 bits.
    Everything I've heard from anyone who's done work on time handling
    libraries is that you absolutely never want to use floating point for
    time. Even if you think that the precision will precisely represent it,
    you don't want to go there; floating point rounding *will* find a way to
    come back and bite you.

    Seconds since epoch is an integral value; using floating point to
    represent an integral value is asking for it.

    As an aside, I also really don't understand why people would want to
    increase the precision of the default return value of time to more than
    second precision. Sub-second precision *isn't available* on quite a few
    platforms, so right away you have portability problems. It's not used by
    the vast majority of applications that currently use time, and I'm quite
    sure that looking at lots of real-world Perl code will back me up on this.
    It may be significantly more difficult, complicated, or slower to get at
    on a given platform than the time in seconds. I just really don't see the
    gain.

    Sure, we need an interface to sub-second time for some applications, but
    please let's not try to stuff it into a single number with seconds since
    epoch.

    --
    Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
  • Bart Lateur at Sep 13, 2000 at 1:52 pm

    On 13 Sep 2000 07:10:30 -0000, Perl6 RFC Librarian wrote:
    In addition, a C<systime> function should be added which provides access
    to the native epoch/system time. For simplification, it might be best if
    this C<systime> function remain the basis for other library-related
    functions, such as C<stat>, C<lstat>, and so on, which typically rely on
    native system time.
    Eek! No!

    Next you'll tell me that

    scalar localtime((stat $file)[9])

    will return incorrect results on some platforms!

    Making time uniform across platforms, so that the numerical value for a
    certain date/time is independent on the platform, is a good idea, but
    don't tell me that we'll have two different representations, for which
    we may or may not need a conversion! ONE time for the whole perl, thank
    you.

    n.b. This time value should be independent of time zones or Daylight
    Savings Time.

    --
    Bart.
  • Charles Lane at Sep 14, 2000 at 12:09 pm

    Chaim Frenkel writes:
    "AD" == Andy Dougherty <doughera@lafayette.edu> writes:
    AD> In my humble opinion, I think perl's time() ought to just call the C
    AD> library's time() function and not waste time mucking with the return
    AD> value. Instead, if the time is to be stored externally for later use by
    AD> another program, the programmer should be responsible for converting the
    AD> time into a suitably useful and portable format. Any unilateral choice
    AD> made by Perl6 in that regard isn't going to be of any help unless everyone
    AD> else (Java, Python, C, etc.) follows along.
    From the perspective of a non-Unix user that has been fighting this battle
    for a few years now, you can't just take the C library time() on all systems.
    And yes, the programmer does need to take responsibility for external formats,
    regardless of the internal time representation used, and regardless of what
    "everyone else is doing".

    On at least some non-Unix systems, the time() function is itself an attempt
    to emulate Posix functionality...note that I say "attempt". And also note
    that Posix != Unix. One can have library functions in perfect compliance
    with published Posix standards, but when Unix programmers see the result
    they say "that's evil".

    An example: gmtime() on my system returns 0. Why? Because the system
    runs on "local time" and has no idea of the offset to UT.
    It's a perfectly Posix-compliant result, but causes no end of problems
    with programs written for Unix. Ditto for the epoch of 1 Jan 1970 0h
    in local time rather than UT.

    -> programmers make assumptions based on what they're used to
    Possibly a few functions to make it easy.

    $Perl::EpochOffset

    0 on a unix box
    966770660 on a Mac (Lifted from pudge's previous email)
    etc.
    I don't know how many places there's an implicit "Epoch=0" embedded
    deeply in Perl modules and apps, but I've run into plenty of them.
    Adding a module to define epochs will sure help, but as long as the
    "default" is so simple, plenty of programmers will just assume Epoch=0
    and build it into their code.

    So my suggestion is that either Epoch=0 for everyone, or make it
    distinctly non-zero for everyone so lazy programmers have to use
    $Perl::EpochOffset everywhere.
    One other that might be useful is have strftime() (or something
    similar) built-in without having to use POSIX; and the default should
    be YYYYMMDDHHMMSS.fffffff, (the ISO format)
    Sounds really good to me.
    I personally prefer to pass around the string representation, more
    that perl and unix systems need to handle datetime. (And I find it
    easier to read the ISO version than a time in seconds)
    Agreed, and having built in functions that can convert to/from ISO
    format to internal representation would be a great help.

    Just to stir things up a bit: if you want to consider abandoning the
    "unix standard time()" to get higher resolution, etc., take a closer
    look at the VMS native time, modified to be UT rather than local
    time.

    It has 64 bits for a huge range, with "ticks" of 100ns. The epoch is
    17-Nov-1858 so no problems with pre-1970 dates in databases...and I
    *believe* that epoch date comes from the "modified Julian Day" epoch
    (MJD = JD - 2,400,000) so there's a very simple conversion to Julian Day.
    --
    Drexel University \V --Chuck Lane
    ======]---------->--------*------------<-------[===========
    (215) 895-1545 _/ \ Particle Physics
    FAX: (215) 895-5934 /\ /~~~~~~~~~~~ lane@duphy4.physics.drexel.edu
  • Andy Dougherty at Sep 14, 2000 at 2:07 pm

    On Thu, 14 Sep 2000, Charles Lane wrote:

    From the perspective of a non-Unix user that has been fighting this battle
    for a few years now, you can't just take the C library time() on all systems.
    Sorry, I don't know what that sentence means.
    On at least some non-Unix systems, the time() function is itself an attempt
    to emulate Posix functionality...note that I say "attempt". And also note
    Do you mean that the following program might not print '5' (well, about 5,
    given sleep's uncertaintites ...)

    #include <stdio.h>
    #include <sys/types.h>
    #include <time.h> /* May need sys/time.h instead */
    int main(void)
    {
    time_t start, stop;
    start = time((time_t *) 0);
    sleep(5);
    stop = time((time_t *) 0);
    return printf("The difference is %ld seconds.\n", stop - start);
    }

    If you mean the above program won't print '5', then I don't see how
    changing the epoch could possibly help. More radical surgery is required.

    If you mean the above program _will_ print '5', then I'd say the system
    has a fine time() function, whatever epoch it uses, and I think perl
    should use that time() function.
    I don't know how many places there's an implicit "Epoch=0" embedded
    deeply in Perl modules and apps, but I've run into plenty of them.
    I agree those are portability bugs in those modules and apps. Just like
    assumptions that '/' is the directory separator, and that integers are 32
    bits long, and many of the other problems cited in perlport.pod.
    Adding a module to define epochs will sure help, but as long as the
    "default" is so simple, plenty of programmers will just assume Epoch=0
    and build it into their code.
    Sadly true.
    So my suggestion is that either Epoch=0 for everyone, or make it
    distinctly non-zero for everyone so lazy programmers have to use
    $Perl::EpochOffset everywhere.
    This is not a simple either-or. Suppose you are using a Mac and that
    perl6 decides to use the Unix epoch. Suppose you want to communicate with
    other Mac programs or library functions about time (e.g. perhaps by
    calling things through the XS interface or by storing to a file). Since
    the perl6 time() and C time() will now disagree about what time it is,
    even the non-lazy programmer will have to use $Perl::EpochOffset
    everywhere.

    In sum, *either* approach works in some situations and fails in others.

    There is no universal solution. Epoch=0 everywhere will *not* solve all
    problems. Nor will Epoch=native. Neither is perfect. Each has problems.

    So we have to pick a default. (Yes, I'm sure everyone agrees that making
    it easy to make the other choice via some nice module is nice too.) But we
    have to pick a default. And I vote for perl's time() simply calling the
    system time().

    --
    Andy Dougherty doughera@lafayette.edu
    Dept. of Physics
    Lafayette College, Easton PA 18042
  • Chris Nandor at Sep 14, 2000 at 2:29 pm

    At 10:08 -0400 2000.09.14, Andy Dougherty wrote:
    This is not a simple either-or. Suppose you are using a Mac and that
    perl6 decides to use the Unix epoch. Suppose you want to communicate with
    other Mac programs or library functions about time (e.g. perhaps by
    calling things through the XS interface or by storing to a file). Since
    the perl6 time() and C time() will now disagree about what time it is,
    even the non-lazy programmer will have to use $Perl::EpochOffset
    everywhere.
    There's also the possibility of time accepting an argument, where 0 would
    be perl's time and 1 would be native time, or something.

    --
    Chris Nandor pudge@pobox.com http://pudge.net/
    Open Source Development Network pudge@osdn.com http://osdn.com/
  • Andy Dougherty at Sep 14, 2000 at 3:01 pm

    On Thu, 14 Sep 2000, Chris Nandor wrote:

    There's also the possibility of time accepting an argument, where 0 would
    be perl's time and 1 would be native time, or something.
    Now that's a clever idea. Hmm. I think I like it as a solution to the
    specific issue at hand better than the proposed time()/systime() pair.
    I think I'll "borrow" your suggestion for a longer posting on
    perl6-language :-).

    On the other hand, I'm not sure I like it too much as a general solution
    to the broader portable vs. native issue, since other functions with
    arguments can't be handled so cleanly.

    Yes, I know it's very very unfair to take your time() suggestion and try
    to apply it to a question like "Should unlink() on VMS unlink all previous
    versions (i.e. like a command line PURGE) or should it behave more like
    DEL and only delete the latest version?

    But the unlink() question is also a valid one with many of the same
    underlying issues. I'm currently trying to think about how to encourage
    us collectively to handle similar issues in similar ways.

    --
    Andy Dougherty doughera@lafayette.edu
    Dept. of Physics
    Lafayette College, Easton PA 18042
  • Chris Nandor at Sep 14, 2000 at 3:28 pm

    At 11:01 -0400 2000.09.14, Andy Dougherty wrote:
    On Thu, 14 Sep 2000, Chris Nandor wrote:

    There's also the possibility of time accepting an argument, where 0 would
    be perl's time and 1 would be native time, or something.
    Now that's a clever idea. Hmm. I think I like it as a solution to the
    specific issue at hand better than the proposed time()/systime() pair.
    I think I'll "borrow" your suggestion for a longer posting on
    perl6-language :-).
    Be my guest. I am not favoring one solution or another, just throwing out
    ideas. I had tossed around the idea of drawing up several competing RFCs.
    :-)

    BTW, Nat noted that a moratorium on RFCs is FAST approaching, that Larry
    will make his draft feature set on Oct. 1, and his final on Oct. 14, so get
    any new RFCs in now. See http://use.perl.org/ for links to what Nat said.

    On the other hand, I'm not sure I like it too much as a general solution
    to the broader portable vs. native issue, since other functions with
    arguments can't be handled so cleanly.
    True.

    Yes, I know it's very very unfair to take your time() suggestion and try
    to apply it to a question like "Should unlink() on VMS unlink all previous
    versions (i.e. like a command line PURGE) or should it behave more like
    DEL and only delete the latest version?

    But the unlink() question is also a valid one with many of the same
    underlying issues. I'm currently trying to think about how to encourage
    us collectively to handle similar issues in similar ways.
    Well, I don't think it is entirely unfair. Also, what values do -T and
    stat() return? Well, -T is not so much of a problem as long as the epoch
    is still in seconds, but stat() sure is a problem. We could make stat take
    an optional second parameter. I don't think any other builtin would have
    the problem, but what about modules like Time::Local?

    --
    Chris Nandor pudge@pobox.com http://pudge.net/
    Open Source Development Network pudge@osdn.com http://osdn.com/
  • Philip Newton at Sep 14, 2000 at 3:06 pm

    On Thu, 14 Sep 2000, Andy Dougherty wrote:

    Do you mean that the following program might not print '5' (well, about 5,
    given sleep's uncertaintites ...)

    #include <stdio.h>
    #include <sys/types.h>
    #include <time.h> /* May need sys/time.h instead */
    int main(void)
    {
    time_t start, stop;
    start = time((time_t *) 0);
    sleep(5);
    stop = time((time_t *) 0);
    return printf("The difference is %ld seconds.\n", stop - start);
    } [snip]
    I agree those are portability bugs in those modules and apps. Just like
    assumptions that '/' is the directory separator, and that integers are 32
    bits long, and many of the other problems cited in perlport.pod.
    You have another assumption up there: that time_t == signed long (since
    you're printing it with %ld) with a resolution of seconds (since you say
    "%ld seconds"). ISO/IEC 9899:1999 (draft C standard, the only C standard-y
    thing I have around) says that time_t is an "arithmetic type" (OK, so
    you're allowed to subtract one from another) "capable of representing
    time", and that "the range and precision representable in clock_t and
    time_t are implementation-defined". So subtracting them may not give you
    seconds since any epoch (that's what the difftime() is for; it explicitly
    gives you seconds of difference, as a double), and even if you knew it
    did, there's no guarantee that %ld is the correct format to print it out.
    Might as well be %llu or %d as %ld.

    Maybe POSIX makes more guarantees.

    Cheers,
    Philip
    --
    Philip Newton <newton@newton.digitalspace.net>
  • Chris Nandor at Sep 14, 2000 at 3:35 pm

    At 11:05 -0400 2000.09.14, Philip Newton wrote:
    You have another assumption up there: that time_t == signed long (since
    you're printing it with %ld) with a resolution of seconds (since you say
    "%ld seconds"). ISO/IEC 9899:1999 (draft C standard, the only C standard-y
    True. In Mac OS, time_t is unsigned long (that is how it can start at
    1904-01-01 00:00:00 (local time) and still be valid today while still being
    32 bits :).

    Maybe POSIX makes more guarantees.
    I don't think it does, but I am not sure.

    --
    Chris Nandor pudge@pobox.com http://pudge.net/
    Open Source Development Network pudge@osdn.com http://osdn.com/
  • Russ Allbery at Sep 14, 2000 at 10:05 pm

    Philip Newton writes:

    You have another assumption up there: that time_t == signed long (since
    you're printing it with %ld) with a resolution of seconds (since you say
    "%ld seconds"). ISO/IEC 9899:1999 (draft C standard, the only C
    standard-y thing I have around) says that time_t is an "arithmetic type"
    (OK, so you're allowed to subtract one from another) "capable of
    representing time", and that "the range and precision representable in
    clock_t and time_t are implementation-defined".
    Don't pay any attention to anything the draft C standard says about time;
    there were some major changes that were backed out of the final standard,
    so that section of the draft is very misleading.

    The final ISO standard, section 7.23.2.4 paragraph 2, says:

    2 The time function determines the current calendar time. The encoding of
    the value is unspecified.

    I don't see anywhere in the final specification where time_t is guaranteed
    to be an arithmetic type, so you *aren't* guaranteed that you can perform
    math operations on them.

    POSIX does provide this guarantee, along with a few others, but in
    strictly conforming C, the only thing you can do with a time_t is pass it
    to one of the conversion functions or use difftime to compare it to
    another one.
    So subtracting them may not give you seconds since any epoch (that's
    what the difftime() is for; it explicitly gives you seconds of
    difference, as a double), and even if you knew it did, there's no
    guarantee that %ld is the correct format to print it out. Might as well
    be %llu or %d as %ld.
    Maybe POSIX makes more guarantees.
    I'm pretty sure POSIX requires it to be an arithmetic type, as well as
    requiring that the epoch be 1970-01-01T00:00:00+0000, but I'm pretty sure
    it doesn't specify the size (nor should it).

    The C99 way of printing out time_t *if* you're guaranteed it's an
    arithmetic type is:

    #include <inttypes.h>

    time_t now;
    printf(PRIdMAX "\n", (intmax_t) now);

    --
    Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
  • Charles Lane at Sep 14, 2000 at 3:15 pm
    Andy Dougherty writes:
    On Thu, 14 Sep 2000, Charles Lane wrote:
    On at least some non-Unix systems, the time() function is itself an attempt
    to emulate Posix functionality...note that I say "attempt". And also note
    Do you mean that the following program might not print '5' (well, about 5,
    given sleep's uncertaintites ...)

    #include <stdio.h>
    #include <sys/types.h>
    #include <time.h> /* May need sys/time.h instead */
    int main(void)
    {
    time_t start, stop;
    start = time((time_t *) 0);
    sleep(5);
    stop = time((time_t *) 0);
    return printf("The difference is %ld seconds.\n", stop - start);
    }

    If you mean the above program won't print '5', then I don't see how
    changing the epoch could possibly help. More radical surgery is required.
    Run that program during a DST change on my system, and you'll get +-3600
    instead of 5. Yes, more radical surgery IS required, and you can't just
    take the C libraries "time()" function and expect it to be suitable for
    Perl's time(). There's code to deal with this in Perl5's vms/vms.c.
    So my suggestion is that either Epoch=0 for everyone, or make it
    distinctly non-zero for everyone so lazy programmers have to use
    $Perl::EpochOffset everywhere.
    This is not a simple either-or.
    Of course not, it was stating a preference for either of two (out of
    many) possible alternatives. Of those two, I prefer Epoch=0.

    If Perl5 on VMS just used the time() function from the C library we'd
    have Epoch=14400 part of the year and Epoch=18000 the rest of the year.
    Varying from year to year. Think this is a good way to do it? I don't.
    Suppose you are using a Mac and that
    perl6 decides to use the Unix epoch. Suppose you want to communicate with
    other Mac programs or library functions about time (e.g. perhaps by
    calling things through the XS interface or by storing to a file). Since
    the perl6 time() and C time() will now disagree about what time it is,
    even the non-lazy programmer will have to use $Perl::EpochOffset
    everywhere.
    Whenever you communicate outside of Perl and you use "low level" data
    you have to deal with the possibility of mismatches in things like
    formats and representations (number endianness, floating point binary
    representations, and yes, times).

    When you're writing code to port to other applications you *should*
    be looking out for stuff like this.

    The problems that I ran into with Epoch != 0 were purely internal
    to Perl...NOT the place where you'd expect to have to mess around with
    EpochOffsets. That's programmers get sloppy.
    In sum, *either* approach works in some situations and fails in others.

    There is no universal solution. Epoch=0 everywhere will *not* solve all
    problems. Nor will Epoch=native. Neither is perfect. Each has problems. Agreed.
    So we have to pick a default. (Yes, I'm sure everyone agrees that making
    it easy to make the other choice via some nice module is nice too.) But we
    have to pick a default. And I vote for perl's time() simply calling the
    system time().
    Andy, those of us using Perl on VMS for some years have had both defaults.
    So there is some experience with this.

    I've been in the Epoch !=0 mode and it sucked. I vote for Epoch=0 as
    the default.
    --
    Drexel University \V --Chuck Lane
    ======]---------->--------*------------<-------[===========
    (215) 895-1545 _/ \ Particle Physics
    FAX: (215) 895-5934 /\ /~~~~~~~~~~~ lane@duphy4.physics.drexel.edu
  • Chris Nandor at Sep 14, 2000 at 3:38 pm

    At 11:15 -0400 2000.09.14, Charles Lane wrote:
    I've been in the Epoch !=0 mode and it sucked. I vote for Epoch=0 as
    the default.
    Well, Perl is about making things easy. What is the most common case,
    needing an arbitrary value of time that may or may not be used to transfer
    between platforms, or needing a value of time that is specific to a given
    platform?

    As noted, I can rarely rely on the Mac value anyway, since it changes with
    time zone. And I cannot think of a time when I have needed the actual Mac
    value to communicate with another Mac process or library. If the Perl
    epoch were used for MacPerl, I don't think I would _ever_ need to get the
    Mac OS epoch (though I would certainly want it available if necessary). I
    can't say the same for VMS, or for other Mac users.

    --
    Chris Nandor pudge@pobox.com http://pudge.net/
    Open Source Development Network pudge@osdn.com http://osdn.com/
  • Andy Dougherty at Sep 14, 2000 at 3:58 pm

    On Thu, 14 Sep 2000, Chris Nandor wrote:

    Well, Perl is about making things easy. What is the most common case,
    needing an arbitrary value of time that may or may not be used to transfer
    between platforms, or needing a value of time that is specific to a given
    platform?
    And I cannot think of a time when I have needed the actual Mac
    value to communicate with another Mac process or library.
    Well, my entire experimental temperature control system currently relies
    on just this communication. But I suspect my personal experience here is
    probably not the most common :-).

    --
    Andy Dougherty doughera@lafayette.edu
    Dept. of Physics
    Lafayette College, Easton PA 18042
  • Chris Nandor at Sep 14, 2000 at 4:02 pm

    At 11:59 -0400 2000.09.14, Andy Dougherty wrote:
    On Thu, 14 Sep 2000, Chris Nandor wrote:

    Well, Perl is about making things easy. What is the most common case,
    needing an arbitrary value of time that may or may not be used to transfer
    between platforms, or needing a value of time that is specific to a given
    platform?
    And I cannot think of a time when I have needed the actual Mac
    value to communicate with another Mac process or library.
    Well, my entire experimental temperature control system currently relies
    on just this communication. But I suspect my personal experience here is
    probably not the most common :-).
    Yeah. :)

    --
    Chris Nandor pudge@pobox.com http://pudge.net/
    Open Source Development Network pudge@osdn.com http://osdn.com/
  • Nathan Wiger at Sep 16, 2000 at 6:19 pm
    Standardize ALL Perl platforms on UNIX epoch
    I've seen lots of discussion on this, and there have been 2 previous
    versions worth of discussion as well. The first version of this was
    actually entitled:

    "Maintain internal time in Modified Julian (not epoch)"

    but that got shot down so fast it wasn't even funny.

    I think Chuck hit the nail on the head with this:

    I've been in the Epoch !=0 mode and it sucked. I vote for
    Epoch=0 as the default.

    The overwhelming consensus in the previous discussions was:

    1. There are problems with every epoch. *EVERY* epoch.

    2. Optimize for Perl.

    Now, one thing that should probably be explored is creating a time
    object, similar to the date object specified in RFC 48. In fact, I'd
    just assume "All Perl core functions should return objects", and hence
    the reason I wrote RFC 73. ;-)

    Seems to me something like this:

    $t = time; # time object

    $t++; # ->NUMBER, same as ->unix
    print "$t"; # ->STRING, same as ->iso

    $t->unix # UNIX epoch seconds
    $t->iso # ISO format
    $t->native # native epoch, whatever that may be

    Kicks ass. 64 bits should be used wherever possible. The time object can
    be passed anywhere and everywhere, and builtin functions know which
    member methods to call to get what they want.

    This is the type of power I'd like in Perl 6. Just looking at it make me
    giddy. Thoughts?

    -Nate
  • Chris Nandor at Sep 17, 2000 at 3:57 pm

    At 11:10 -0700 2000.09.16, Nathan Wiger wrote:
    Now, one thing that should probably be explored is creating a time
    object, similar to the date object specified in RFC 48. In fact, I'd
    just assume "All Perl core functions should return objects", and hence
    the reason I wrote RFC 73. ;-)
    And it would make me stop using Perl faster than your object method could
    be resolved.

    --
    Chris Nandor pudge@pobox.com http://pudge.net/
    Open Source Development Network pudge@osdn.com http://osdn.com/
  • Chris Nandor at Sep 17, 2000 at 4:02 pm

    At 11:56 -0400 2000.09.17, Chris Nandor wrote:
    At 11:10 -0700 2000.09.16, Nathan Wiger wrote:
    Now, one thing that should probably be explored is creating a time
    object, similar to the date object specified in RFC 48. In fact, I'd
    just assume "All Perl core functions should return objects", and hence
    the reason I wrote RFC 73. ;-)
    And it would make me stop using Perl faster than your object method could
    be resolved.
    Well, Perl 6, anyway ... :)

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

    Chris Nandor wrote:
    just assume "All Perl core functions should return objects", and hence
    the reason I wrote RFC 73. ;-)
    And it would make me stop using Perl faster than your object method could
    be resolved.
    Is your concern one of?

    1. Speed

    2. Bloat

    3. Excess burden on the programmer

    4. Required knowledge of OO to complete simple scripts

    If it's any or all of these, I'm *with you*. I think OO should be
    transparent, under the hood, you don't have to know it's there. See RFC
    159 and RFC 73 for fairly good explanations of this.

    But if you've got other concerns, I'd love to hear them (honestly).

    -Nate
  • Chris Nandor at Sep 18, 2000 at 8:25 pm

    At 9:08 -0700 2000.09.18, Nathan Wiger wrote:
    Chris Nandor wrote:
    just assume "All Perl core functions should return objects", and hence
    the reason I wrote RFC 73. ;-)
    And it would make me stop using Perl faster than your object method could
    be resolved.
    Is your concern one of?

    1. Speed

    2. Bloat

    3. Excess burden on the programmer

    4. Required knowledge of OO to complete simple scripts Yes.
    If it's any or all of these, I'm *with you*. I think OO should be
    transparent, under the hood, you don't have to know it's there. See RFC
    159 and RFC 73 for fairly good explanations of this.
    I think it shouldn't exist in core functions.

    --
    Chris Nandor pudge@pobox.com http://pudge.net/
    Open Source Development Network pudge@osdn.com http://osdn.com/

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupperl6-language-datetime @
categoriesperl
postedSep 13, '00 at 7:10a
activeSep 24, '00 at 7:54p
posts50
users10
websiteperl6.org

People

Translate

site design / logo © 2021 Grokbase