Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

J. David Blackstone wrote: > I always treat the return value of time() as a black-box value. I >can perform specific actions on it, such as feeding it to localtime() >or adding relative time intervals to it, such as a year of seconds. >But I do not allow myself to look at that value. I was ki

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

> On Tue, Aug 15, 2000 at 09:25:34AM -0700, Larry Wall wrote: > > [EMAIL PROTECTED] writes: > > : Yep. Or more generally "Standardize Perl on all platforms to one > > : common time epoch" and reccommend the Unix epoch since it's so > > : widespread. :-) > > > > Oh, gee, where's your sense of his

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

On Tue, Aug 15, 2000 at 09:25:34AM -0700, Larry Wall wrote: > [EMAIL PROTECTED] writes: > : Yep. Or more generally "Standardize Perl on all platforms to one > : common time epoch" and reccommend the Unix epoch since it's so > : widespread. :-) > > Oh, gee, where's your sense of history? (As in

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

On Tue, 15 Aug 2000, Nathan Wiger wrote: > Jarkko Hietaniemi wrote: > > > > > Is Perl currently using different epochs on different platforms? If so, I > > > > Yes. MacOS and VMS. (Though VMS' localtime() uses the UNIX definition, > > just to be portable.) MacOS' epoch zero is 1900 (or was i

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

>> Is Perl currently using different epochs on different platforms? If so, I > > Yes. MacOS and VMS. (Though VMS' localtime() uses the UNIX definition, > just to be portable.) MacOS' epoch zero is 1900 (or was it 1901?), > VMS' epoch zero is 17-NOV-1858 00:00:00.00, for some astronomical > rea

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

> On 14 Aug 2000, Russ Allbery wrote: > >> Day resolution is insufficient for most purposes in all the Perl scripts >> I've worked on. I practically never need sub-second precision; I almost >> always need precision better than one day. >> > > MJD allows fractional days (otherwise it would of co

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

There is already precedent (-M, et alia) for a "perl epoch" which is time since the start of execution of the script. Negative numbers are used to represent times prior to the start of execution, and positive numbers are used to represent times after the start of execution. The "perl epoch" does

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

[EMAIL PROTECTED] writes: > Midnight, Jan 1, 2000, Greenwich time > > seems like a good candidate. have found 2000-03-01 to be a good epoch. It makes -mm-dd decoding and leap year calculations cheaper/simpler as it is the closest start of a new 400 yea

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

At 02:23 PM 8/15/00 -0400, [EMAIL PROTECTED] wrote: >Modified Julian Day 0 thus started on 17 Nov 1858 (Gregorian) at 00:00:00 >UTC. >(somebody threw that date out, It appears to be purely >arbitrary rather than based on some celestial event) Not arbitrary at all. From: http://www.kgb.com/calend.

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

Jonathan wrote: > >On Tue, Aug 15, 2000 at 09:45:55AM -0700, Nathan Wiger wrote: >> I don't know about this. Sounds cool, but I think we should stick to >> something that somebody somewhere uses already. Of course, something >> standard like 0 AD isn't bad. > >Standard for whom? I bet there are

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

In message <[EMAIL PROTECTED]> Dan Sugalski <[EMAIL PROTECTED]> wrote: > I think I'd snag a date after the last western country went Julian, just to > avoid some of the less fun time conversion issues. (How long ago Jan 1, > 1690 was depends on what country you're in) I think you mean

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

Jonathan Scott Duff wrote: > >> standard like 0 AD isn't bad. > > Standard for whom? I bet there are *millions* of Jews for whom "0 AD" > is meaningless. s/Jews/ calendar that predates christianity>/ Good point. Unix epoch it is! :-) -Nate

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

At 09:25 AM 8/15/00 -0700, Larry Wall wrote: >[EMAIL PROTECTED] writes: >: Yep. Or more generally "Standardize Perl on all platforms to one >: common time epoch" and reccommend the Unix epoch since it's so >: widespread. :-) > >Oh, gee, where's your sense of history? (As in creating our own. :-

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

On Tue, Aug 15, 2000 at 09:45:55AM -0700, Nathan Wiger wrote: > I don't know about this. Sounds cool, but I think we should stick to > something that somebody somewhere uses already. Of course, something > standard like 0 AD isn't bad. Standard for whom? I bet there are *millions* of Jews for wh

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

On Tue, Aug 15, 2000 at 09:25:34AM -0700, Larry Wall wrote: > [EMAIL PROTECTED] writes: > : Yep. Or more generally "Standardize Perl on all platforms to one > : common time epoch" and reccommend the Unix epoch since it's so > : widespread. :-) > > Oh, gee, where's your sense of history? (As in

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

Larry Wall wrote: > > Oh, gee, where's your sense of history? (As in creating our own. :-) > Maybe we should invent our own epoch, like the year 2000. Or use a > really standard one, like the year 0 AD (aka 1 BC). I don't know about this. Sounds cool, but I think we should stick to something t

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

[EMAIL PROTECTED] writes: : Yep. Or more generally "Standardize Perl on all platforms to one : common time epoch" and reccommend the Unix epoch since it's so : widespread. :-) Oh, gee, where's your sense of history? (As in creating our own. :-) Maybe we should invent our own epoch, like the ye

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

On Tue, Aug 15, 2000 at 08:44:48AM -0700, Nathan Wiger wrote: > There seems to be a groundswell against this idea, which is fine by me > (heck, just because it's my idea doesn't me it's a GOOD one!). > > Here's a different proposal, same vein: "Standardize all Perl platforms > on the UNIX epoch".

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

Jarkko Hietaniemi wrote: > > > Is Perl currently using different epochs on different platforms? If so, I > > Yes. MacOS and VMS. (Though VMS' localtime() uses the UNIX definition, > just to be portable.) MacOS' epoch zero is 1900 (or was it 1901?), > VMS' epoch zero is 17-NOV-1858 00:00:00.0

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

On Mon, Aug 14, 2000 at 08:40:32PM -0700, Nathan Wiger wrote: > No, but currently Perl IS forcing Windows, Mac, and BeOS users to > understand what the UNIX epoch is. So you're proposing that rather than give one platform (unix) an advantage, we force all platforms to use some other completely a

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

At 10:56 PM 8/14/00 -0500, Jarkko Hietaniemi wrote: > > Is Perl currently using different epochs on different platforms? If so, I > >Yes. MacOS and VMS. (Though VMS' localtime() uses the UNIX definition, >just to be portable.) MacOS' epoch zero is 1900 (or was it 1901?), >VMS' epoch zero is 17

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

> "RA" == Russ Allbery <[EMAIL PROTECTED]> writes: RA> Is Perl currently using different epochs on different platforms? If so, I RA> can definitely see the wisdom in doing something about *that* and RA> off-loading the system-local time processing into modules (although I can RA> also see th

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

Tim Jenness <[EMAIL PROTECTED]> writes: > On 14 Aug 2000, Russ Allbery wrote: >> Day resolution is insufficient for most purposes in all the Perl >> scripts I've worked on. I practically never need sub-second precision; >> I almost always need precision better than one day. > MJD allows fractio

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

On 14 Aug 2000, Russ Allbery wrote: > Day resolution is insufficient for most purposes in all the Perl scripts > I've worked on. I practically never need sub-second precision; I almost > always need precision better than one day. > MJD allows fractional days (otherwise it would of course be us

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

> Yes. MacOS and VMS. (Though VMS' localtime() uses the UNIX definition, > just to be portable.) MacOS' epoch zero is 1900 (or was it 1901?), 1904 (if it matters). Damian

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

> Is Perl currently using different epochs on different platforms? If so, I Yes. MacOS and VMS. (Though VMS' localtime() uses the UNIX definition, just to be portable.) MacOS' epoch zero is 1900 (or was it 1901?), VMS' epoch zero is 17-NOV-1858 00:00:00.00, for some astronomical reason IIRC.

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

Nathan Wiger <[EMAIL PROTECTED]> writes: >> Anyway, it doesn't matter; it's a lot more widely used than any other >> epoch, and epochs are completely arbitrary anyway. What's wrong with >> it? > I think the "What's wrong with it?" part is the wrong approach to this > discussion. That's exactly

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

> Anyway, it doesn't matter; it's a lot more widely used than any other > epoch, and epochs are completely arbitrary anyway. What's wrong with it? I think the "What's wrong with it?" part is the wrong approach to this discussion. Personally, I'm a 100% UNIX head. All I work on is UNIX (thank hea

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

Tim Jenness <[EMAIL PROTECTED]> writes: > Of course, "seconds since 1970" is only obvious to unix systems > programmers. I disagree; I don't think that's been true for a while. It's certainly familiar, if not obvious, to *any* Unix programmer (not just systems programmers), as it's what time()

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

On 14 Aug 2000, Russ Allbery wrote: > Nathan Wiger <[EMAIL PROTECTED]> writes: > > > The idea would be twofold: > > >1. time() would still return UNIX epoch time. However, it > > would not be in core, and would not be the primary > > timekeeping method. It would be in Time::Loca

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

Nathan Wiger <[EMAIL PROTECTED]> writes: > The idea would be twofold: >1. time() would still return UNIX epoch time. However, it > would not be in core, and would not be the primary > timekeeping method. It would be in Time::Local for > compatibility (along with localtime

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

On Mon, 14 Aug 2000, Nathan Wiger wrote: >1. time() would still return UNIX epoch time. However, it > would not be in core, and would not be the primary > timekeeping method. It would be in Time::Local for > compatibility (along with localtime and gmtime). > >2. mjdate(

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

> > I'm not sure anyone does that much in the way of time/date work that it'd > > make a difference. Besides, we're talking internal here--time() may still > > return Unix epoch seconds for compatibility reasons. > > Blah! I saw the prosal for an mjdate() routine and thought it was at > the lang