Here are some comments from Matthias Neeracher, the MacPerl author, and a
few comments from me.
>To: Chris Nandor <[EMAIL PROTECTED]>
>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 <[EMAIL PROTECTED]>
>
>In message <p04320408b5bfc61cab94@[192.168.0.77]> you write:
>>I am on the new [EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> 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 | [EMAIL PROTECTED] | http://pudge.net/
Andover.Net | [EMAIL PROTECTED] | http://slashcode.com/
