Front page | perl.perl6.language.datetime |
Postings from August 2000
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/Thread Next