develooper Front page | perl.perl6.language.datetime | Postings from August 2000

Re: RFC 99 (v2) Standardize ALL Perl platforms on UNIX epoch

Thread Next
Chris Nandor
August 17, 2000 15:05
Re: RFC 99 (v2) Standardize ALL Perl platforms on UNIX epoch
Message ID:
Here are some comments from Matthias Neeracher, the MacPerl author, and a
few comments from me.

>To: Chris Nandor <>
>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 <>
>In message <p04320408b5bfc61cab94@[]> you write:
>>I am on the new 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.
>>>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.

>>>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 Neeracher   <>
>   "These days, though, you have to be pretty technical before you can
>    even aspire to crudeness." -- William Gibson, _Johnny Mnemonic_

Chris Nandor       |      |
Andover.Net        | |

Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About