dankogai@jms.jeton.or.jp (Dan Kogai) writes: >My name is Dan Kogai, a network consultant who uses perl intensively on busi >ness. My choice of Internet client is a Mac and server Unix I recently dow >nloaded MacPerl 5.07r1m and instantly it hit my soul--it is one of the best >perl implementations! Thanks :-) [Dan then tries to run newtimelocal.pl and finds a bug...] > I took a look at the code and output carefully and found the "epoch-making >difference"; Perl's time() was supposed to return seconds since 1970/01/01 ( >or Epoch) like time() of Unix system call. Mac's time(), on the other hand, >returns seconds since 1904/01/01 just like that of toolbox and HyperTalk's " >the seconds". as a result timegm() of my newtimelocal.pl was off 2082877200 >seconds, or whatever &timegm(0,0,0,1,0,70) of original timelocal.pl returns. Yup. > I first thought of rewriting newtimelocal.pl so that it is compatible with >Mac's time() (The crude way to do so is to add 2082877200 to the result of " >unix" timelocal when $[ =~ /Mac/). But perl's manual was quite clear its Ep >och, mother of all time, is 1970/01/01. Yes, I just found that confirmed in the Perl 5 manual. IMHO, the documentation should be changed, not my code, i.e. =item time Returns the number of non-leap seconds since 00:00:00 UTC, January 1, 1970. Suitable for feeding to gmtime() and localtime(). in perfunc.pod should be changed to something like =item time Returns the number of non-leap seconds since a system specific date (00:00:00 UTC, January 1, 1970 on UNIX systems). Suitable for feeding to gmtime() and localtime(). > So I would like to ask you guys this; should time() of MacPerl be correct >ed *changed* :-) >or leave it as is?. I think the best way to go is to correct time() of M >acPerl and add mactime() function which returns seconds since MacEpoch, 1904 >/01/01. Tell me what you think. As veteran subscribers to this [MacPerl] mailing list can surely recall, my position on questions like these is essentially: - For functions that directly map to ISO C/POSIX.1 concepts, Perl programmers should not expect any guarantees beyond what those standards say. - Issues left implementation defined by those standards are resolved in favor of existing Macintosh precedents if such exist. Otherwise, they are resolved to follow typical Unix implementations as far as possible. The tricky part about these principles is that ISO C doesn't define the Epoch to be used. POSIX.1 defines it as Jan 1, 1970, but all Mac compilers define it as Jan 1, 1904. I prefer in this case to follow the Mac precedent and have times returned by time, stat, and so on based on the 1904 date not the 1970 one. However, if the Perl5-porters mailing list rejects this view, I might reconsider.