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 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 have this horror that people will still be using 1970 as the epoch in the year 31,536. I tend to thing this whole epoc thing is overblown. Few people would know what this time was just by looking at it: 966421517 So what does it matter if that time was represented by another string of digits? What difference does it _really_ make what epoc is used, so long as it's fully integrated into the language and interfaces along with appropriate conversions to other epocs? I tend to think that perl time should not break when presented with Larry's date of birth :-) We also need to avoid the unixtime 2038 bug, one way or another.. Tim. p.s. For reference, Oracle DATE type can handle all dates from January 1, 4712 BC to December 31, 4712 AD. Oracle also supports a very wide range of date formats and can use one of several calendars (Arabic Hijrah, English Hijrah, Gregorian, Japanese Imperial, Persian, ROC Official (Republic of China) and Thai Buddha).
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 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 have this horror that people will still be using 1970 as the epoch in the year 31,536. Actually, Damian Conway came up with a good one last night. His suggestion was that the time at which we decide what to use as the start of our epoch, should be the time that we use as the start of our epoch. Now that's creating our own history!
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 useless). As I write this the MJD is 51771.20833 I recognize that a lot of software packages out there are using MJD, but I don't really feel that fractions of days, hours, or minutes are intuitive. Mankind has had sixty seconds in a minute, sixty minutes in an hour, twelve hours in a day, and so on up, for centuries. Arguably, better systems could be created, and perhaps MJD is such a system, but it is very hard to change the instincts and habits built on older systems. (Just look at how slowly the U.S. is moving to metric.) I would really rather not see this change, or see the number expressed in seconds. (MJD as seconds would really amount to just moving the epoch, and I don't think that would make anyone happy.) I still lean towards thinking that anything involving a date should be pushed out into a module. There could be a date module (or two) included as standard, and people who want MJD or other systems, or fractions of a second, or whatever, could totally ignore the standard module and use a different one. J. David
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". Sound better? Yep. Or more generally "Standardize Perl on all platforms to one common time epoch" and reccommend the Unix epoch since it's so widespread. :-) -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
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 year 2000. Or use a really standard one, like the year 0 AD (aka 1 BC). I have this horror that people will still be using 1970 as the epoch in the year 31,536. Larry
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.00, for some astronomical reason IIRC. This is the real point I'm trying to address. Nothing else. :-) 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". Sound better? -Nate
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.html This information comes from the original (pre-Motif) DECwindows help file which accompanied VMS version 5.3. by Marios Cleovoulou http://ourworld.compuserve.com/homepages/cleovoulou/ Copyright © 1988, 1989 by Digital Equipment Corporation. The Julian Period Astronomers use the Julian period because it is convenient to express long time intervals in days rather than months, weeks and years. It was devised by Joseph Scaliger, in 1582, who named it after his father Julius, thus creating the confusion between the Julian (Caesar) calendar and the Julian (Scaliger) period. Julian Day 1 began at 12:00 noon, January 1, 4713 BC. This date was thought by some to correspond approximately to the beginning of the universe. Certainly it predated any known astronomical events known in the 16th century without resorting to negative times. Scaliger decided on the actual date on the grounds that it was the most recent coincidence of three major chronological cycles: - The 28-year solar cycle, after which dates in the Julian calendar (for example September 27) return to the same days of the week (for example Tuesday). - The 19-year lunar cycle, after which phases of the moon return to the same dates of the year. - The 15-year indiction cycle, used in ancient Rome for tax regulation. It takes 7980 years to complete the cycle. Noon of January 1, 1988, marks the beginning of Julian Day 2447161. The Julian period is also of interest because of its use as a time base by the VMS operating system. VMS and the Julian Period or: Why VMS regards November 17, 1858, as the beginning of time... The modified Julian date adopted by SAO (Smithsonian Astrophysical Observatory) for satellite tracking is Julian Day 240, which turns out to be November 17, 1858. SAO started tracking satellites with an 8K (nonvirtual) 36-bit IBM 704 in 1957, when Sputnik went into orbit. The Julian day was 2435839 on January 1, 1957. This is 11225377 octal, which was too big to fit into an 18-bit field. With only 8K of memory, the 14 bits left over by keeping the Julian date in its own 36-bit word would have been wasted. They also needed the fraction of the current day (for which 18 bits gave enough accuracy), so it was decided to keep the number of days in the left 18 bits and the fraction of a day in the right 18 bits of one word. Eighteen bits allows the truncated Julian day (the SAO day) to grow as large as 262143, which from November 17, 1858, allowed for 7 centuries. Possibly, the date could only grow as large as 131071 (using 17 bits), but this still covers 3 centuries and leaves the possibility of representing negative time. The 1858 date preceded the oldest star catalogue in use at SAO, which also avoided having to use negative time in any of the satellite tracking calculations. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
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 Gregorian, not Julian. If that's going to be your requirement then you need to pick a date in the 20th century I think as IIRC Russia didn't go Gregorian until then... Tom -- Tom Hughes ([EMAIL PROTECTED]) http://www.compton.nu/ ...I haven't had sex in so long, I forget who gets tied up!
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 arbitrary date/time format? There's some other advantages to MJD beyond system-independence. Namely, it allows easy date arithmetic, meaning complex objects are not required to modify dates even down to the nanosecond level. Sorry, but date arithmetic is easy now: $then = time(); # time passes $now = time(); $difference = $now - $then; # How long was that? And as to modifying dates "down to the nanosecond", you're proposing that these MJD dates be floating point numbers. Why not ust make time() return a float and *bam* you've got 1 second precision as far as your floats or doubles can carry you. But make the core language easily accessible to everyone. Funny, that's the exact argument I would use *against* mjdate(). -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
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-NOV-1858 00:00:00.00, for some astronomical reason IIRC. It's the Smithsonian Base Date, FWIW. On VMS, though, perl presents all time in Unix epoch seconds. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
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/any other group of people who have their own calendar that predates christianity/ Good point. Unix epoch it is! :-) -Nate
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 language level for some reason. This RFC should go to -internals so that I don't get confused that way :-) Hey wait, you're both right! :-) 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 and gmtime). 2. mjdate() would return MJD. It _would_ be in core, and it _would_ be the internal timekeeping method. All of the new date functions would be designed to be based off of it. So, just to clarify: 1. The Perl 5 way in Perl 6: use Time::Local; $date = localtime time(); 2. The Perl 6 native way: $date = date mjdate(); Make sense? -Nate
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() returns, and pretty much any C programmer will have used that at some point or another. It's also so widespread as to be at least somewhat familiar to non-Unix programmers. 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? MJD is doable with current perl 32bit doubles. I use it all the time in perl programs and am not suffering from a lack of precision. 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. If we're aiming at replacing time, it has to provide *at least* second precision, at which point I really don't see the advantage of MJD over Unix time. Why change something that works? Is Perl currently using different epochs on different platforms? If so, I can definitely see the wisdom in doing something about *that* and off-loading the system-local time processing into modules (although I can also see the wisdom in leaving well enough alone). But why not go with the most commonly used and most widely analyzed epoch? -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
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 heavens). And that's all I even plan on using; after all, I'm a UNIX sysadmin. So, time() actually makes more sense to me than mjdate(), even though I proposed the RFC. That being said, what we need to say "is it possible UNIX might not be perfect?" (hard to imagine, true... :-). More specifically, "is there something that would work better for putting Perl in Palm pilots, watches, cellphones, Windows and Mac hosts, *plus* everything else it's already in?" Is Perl currently using different epochs on different platforms? No, but currently Perl IS forcing Windows, Mac, and BeOS users to understand what the UNIX epoch is. There's some other advantages to MJD beyond system-independence. Namely, it allows easy date arithmetic, meaning complex objects are not required to modify dates even down to the nanosecond level. One thing C has done well that we can learn from is making libraries system-dependent, but the language system-independent. Leave time() and localtime() (UNIX dependent) in Unix::Time or some other module, easily accessible through a "use Unix::Time". But make the core language easily accessible to everyone. That's where mjdate() comes in, IMO. -Nate
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() would return MJD. It _would_ be in core, and
it _would_ be the internal timekeeping method. All
of the new date functions would be designed to be based
off of it.
So, just to clarify:
1. The Perl 5 way in Perl 6:
use Time::Local;
$date = localtime time();
2. The Perl 6 native way:
$date = date mjdate();
Now, are we talking about the new default/de facto standard that the
users are being presented with? Or are we talking about the true
internal structure? ("and it _would_ be the internal timekeeping
method.")
I don't have an OS that reports time in MJD. It seems
counter-productive (IMHO) for Perl (internally) to convert from
whatever the native platform time measurement is to MJD, only to
convert it back to the native format again, if that never is presented
to the users.
For example:
# From 5.6 perlfunc
$now = time;
utime $now, $now, @ARGV;
Under this proposal, time would (under Unix), return the number of
epoch seconds, which would then be converted to MJD internally. This
stored MJD would then have to be converted back to the original epoch
seconds, (perhaps twice), for the argument to utime? Alarms and
timers, file tests - any time interface outside of Perl itself - these
*all* will be converted to MJD internally?
(Assuming, of course, that you don't explicitly change the arguments to
utime to accept MJD, although it would still have to be converted to
native format anyway.)
I can understand wanting to present the user with a common,
multi-platform, consistent date/time interface, but I don't understand
extending that to the internals.
--
Bryan C. Warnock
([EMAIL PROTECTED])
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 what I disagree with, I think. I don't understand why this would be the wrong approach to the discussion. It seems to me that it follows automatically from "epochs are completely arbitrary anyway." That being said, what we need to say "is it possible UNIX might not be perfect?" (hard to imagine, true... :-). More specifically, "is there something that would work better for putting Perl in Palm pilots, watches, cellphones, Windows and Mac hosts, *plus* everything else it's already in?" How does it make any difference what epoch you use? Why would this make Perl more portable? No, but currently Perl IS forcing Windows, Mac, and BeOS users to understand what the UNIX epoch is. In that case, I don't understand what the difference is between that and forcing those users *plus* Unix users to understand what the MJD epoch is. There's some other advantages to MJD beyond system-independence. But MJD isn't any more system-independent than Unix time. Absolutely nothing about Unix time is specific to Unix; it's just as portable as any other arbitrary epoch. Namely, it allows easy date arithmetic, meaning complex objects are not required to modify dates even down to the nanosecond level. Unix time allows this down to the second level already. If we wanted to allow it down to the nanosecond level through a different interface to return something like TAI64NA or something, that would make sense to me. What doesn't make sense to me is a change of epoch; I just don't see what would be gained. I must be very confused. I don't understand what we gain from MJD dates at all, and the arguments in favor don't make any sense to me; all of the advantages listed apply equally well to the time system we have already. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
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 useless). As I write this the MJD is 51771.20833 If we're aiming at replacing time, it has to provide *at least* second precision, at which point I really don't see the advantage of MJD over Unix time. Why change something that works? It should be able to provide this precision and more. At some level time() will have to be changed to support fractions of a second and this may break current code that uses time() explicitly rather than passing it straight to localtime() and gmtime(). As long as I can do simplistic date arithmetic with the return value of time() and retrieve that from the equivalent date() object I will be happy. -- Tim Jenness JCMT software engineer/Support scientist http://www.jach.hawaii.edu/~timj
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)
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 and gmtime). 2. mjdate() would return MJD. It _would_ be in core, and it _would_ be the internal timekeeping method. All of the new date functions would be designed to be based off of it. Here's the significant problem that I have with this: It feels very much like it's putting the cart before the horse. Perl is fundamentally a Unix language (portable Unix, to a degree). It's core user base has always been sysadmins and hackers with a Unix-like mindset, regardless of the platform they're using. As an example, I've written literally hundreds of scripts that use Unix time in one way or another; it has innumerable really nice properties and is compatible with all the other programs written in other languages that I have to interact with. By comparison, who uses MJD? Practically no one. It's a theoretically nice time scale, but outside of the astronomy community, how many people even have any idea what it is? This appears to be a proposal to replace a *very* well-known time base with very well-known and commonly-used properties with a time base that practically no one knows or currently uses just because some of its epoch properties make slightly more sense. Unless I'm missing something fumdamental here, this strikes me as a horrible idea. Unix's time representation format has no fundamental problems that aren't simple implementation issues. Negative values represent times before 1970 just fine. The range problem is easily solved by making it a 64-bit value, something that apparently we'd need to do with an MJD-based time anyway. And everyone already knows how it works and often relies on the base being consistent with their other applications. It really doesn't sound like a good idea to change all that. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
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 fractional days (otherwise it would of course be useless). As I write this the MJD is 51771.20833 Floating point? Or is the proposal to use fixed-point adjusted by some constant multiplier? (Floating point is a bad idea, IMO; it has some nasty arithmetic properties, the main one being that the concept of incrementing by some small amout is somewhat ill-defined.) At some level time() will have to be changed to support fractions of a second and this may break current code that uses time() explicitly rather than passing it straight to localtime() and gmtime(). Agreed. I guess I don't really care what we use for an epoch for our sub-second interface; I just don't see MJD as obviously better or more portable. I'd actually be tentatively in favor taking *all* of the time stuff and removing it from the core, under the modularity principal, but I don't have a firm enough grasp of where the internals use time to be sure that's a wise idea. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
