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 kind of hoping
Perl6 would formalize this into a black-box value, meaning an object,
and offload everything into a standard module instead of the core.
thinking about it, I like that idea the best.
for a script to really be cross-platform independent (i.e. a "good" script)
then it can't make assumptions about the internal representation of time.
And if its hidden, then you can change epochs, change operating systems,
and change religions, and your script really wont care.
you'd have three basic things you could do:
1) get calendar time, which would return a year, month, day, hour, minute,
second.
defaulting to the gregorian calendar
2) start stopwatch: which sets a stopwatch to zero, and then you can poll
it
to see how much time has elapsed since you started the stop watch.
default units would be seconds
3)perform some arithemetic on these two things.
calendar - calendar = elapsed time
calendar + elapsed time = new calendar time
etc, etc
both of these could be objects and would enforce the black box.
calendar time would be a static object representing a fixed point in time.
stopwatch would be a dynamic object with a reset and polling method
to return time elapsed since last reset.
calendar time would have a method that spits out a string formatted
to the proper, non-ambigous representation,
("16 August, 2000, 11:56 A.M." )
then when 2099 rolls around, there shouldn't be any Y2.1K problem...
;)
Greg London
always planning ahead
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)
(-internals removed from the CC list) [EMAIL PROTECTED] writes: All calendar systems are arbitrary. Yup. So let's use Larry's birthdate-and-time as the epoch marker. Seriously, stick with 1970 (if we need an arbitrary marker, no reason it can't be a familiar one) and extend date/time values to be BigSoddingInts. That'll mean we're not screwed by the +/- 69.summat year problem that will hit the rest of civilization in 2038, and we can do useful calculations like "number of days since Queen Victoria ascended to the throne" without wrapping around in our int space. Nat (BigInts are not an internals headache, so I'm not bothering the internals list, which is right now debating the difference between arrays and matrices)
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 *millions* of Jews for whom "0 AD" is meaningless. s/Jews/any other group of people who have their own calendar that predates christianity/ excerpts from : http://webexhibits.org/calendars/index.html the Islamic calendar is based on the motion of the moon, while the year has no connection with the motion of the earth around the sun. But even worse, you can't just do some math and convert a number of seconds into a old, old date, because the old calendars were so messed up. Before Julius Caesar introduced the Julian calendar in 45 B.C.E., the Roman calendar was a mess, and much of our so-called "knowledge" about it seems to be little more than guesswork. Originally, the year started on 1 March and consisted of only 304 days or 10 months These 304 days were followed by an unnamed and unnumbered winter period. In practice it was the duty of the priesthood to keep track of the calendars, but they failed miserably, partly due to ignorance, partly because they were bribed to make certain years long and other years short. Furthermore, leap years were considered unlucky and were therefore avoided in time of crisis, such as the Second Punic War. The Julian calendar was introduced by Julius Caesar in 45 B.C.E. It was in common use until the 1500s, when countries started changing to the Gregorian calendar. However, some countries (for example, Greece and Russia) used it into this century, and the Orthodox church in Russia still uses it, as do some other Orthodox churches. 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) The calendar used throughout the world today is the Gregorian calendar. It was proposed by Aloysius Lilius, a physician from Naples, and adopted by Pope Gregory XIII in accordance with instructions from the Council of Trent (1545-1563) to correct for errors in the older Julian Calendar. By 1582 vernal equinox had moved (1582-325)/128 days = approximately 10 days backwards (because of the Julian calendar errors) So 10 days had to be dropped. In the Gregorian calendar, the tropical year is approximated as 365 97/400 days = 365.2425 days. Thus it takes approximately 3300 years for the tropical year to shift one day with respect to the Gregorian calendar. The approximation 365 97/400 is achieved by having 97 leap years every 400 years. a year's length is currently 365.242190 days, but it varies. Around 1900 its length was 365.242196 days, and around 2100 it will be 365.242184 days. end of excerpt the further back you go in history, the less accurate your dates will be (if you want to convert a modern calendar date to a Roman calendar date, you'll have a TON of if-then-else's to handle) and even then, some of it is guess work. this seems to rule out the idea of using 0 AD as a reference date. All calendar systems are arbitrary. there is nothing that says solar days are a better measure than lunar months (for a given definition of "better") they are both celestial events, and neither one of them has a fixed, constant, period or rate. you could argue that one is religiously biased, or you could simply say that most of the people developing perl use the gregorian calendar, and the developers get to pick. by the same token, you could say that Greenwich England is a lousy place to define the Universal Time Zone, (the weather is miserable, the food is terrible, and the people are rude) but, hey, almost everyone draws the zeroeth longitude through that city. so most time calculations are based off of the time there. but they happen to be the first to make navigational charts and they had to put zero somewhere. then the term "second" is arbitrary as well. 12 hours in the day and 12 hours in the night (because their happen to be 12 months in the year?) 60 minutes in an hour and 60 seconds in a minute. (there are 360 degrees in a circle because there are about 365 days in a year, and 360 divided very very nicely. and again, it worked out that navigation using sextants wanted to keep things as simple as possible, so easily dividible numbers were quite desirable.) so its all arbitrary. but most people developing perl use the gregorian calendar. and it seems to be fairly widespread as far as calendars go. and in the spirit of "the first ones there get to define the rules", it would seem appropriate that teh perl epoch be based off of some event on the gregorian calendar. given the problems with earlier calendar systems, it should be a recent (in the relative sense of the word recent) event. Midnight, Jan 1, 2000, Greenwich
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)
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 that somebody somewhere uses already. Of course, something standard like 0 AD isn't bad. I have this horror that people will still be using 1970 as the epoch in the year 31,536. Yeah, but by then we'll be on Perl 203.4.2 and it'll be our children's children's children's children's issue (assuming Perl and computers are still around even). Plus, at least the difference between the UNIX epoch and 31,536 is 1970 less than the difference between 0 AD and 31,536. (For those counting bits.) :-) -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. :-) 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 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) While I personally like the smithsonian base date (17-nov-1858) that's rather parochial (well, US-centric) and difficult to remember. If we're picking a new one, I'm partial to Jan 1, 2000. Or shall we choose year 0 in the Chinese calendar? I have this horror that people will still be using 1970 as the epoch in the year 31,536. Nah. I'm sure we'll have switched over to Elvis' birthday as base date by then... :) 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)
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)
"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 the wisdom in leaving well enough alone). But why not go with
RA the most commonly used and most widely analyzed epoch?
Folks, the only problem that everyone seems to be arguing about is
what the EPOCH is. Who cares what the epoch is?
Create $Perl::Time{EPOCH} and be done with it.
As long as I can add and subtract a reasonable range of time values and
get a reasonable result I'm happy.
There should be no assumption that 0 is the epoch. It might well be
that some other arbitrary number is the limit of valid time. So unless
perl is going to distribute portable time and date calcuations, as
part of the core, we will have to live with whatever the system
libraries give us.
(I don't want to think about Leap Seconds just yet.)
chaim
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
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)
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)
[EMAIL PROTECTED] writes: Midnight, Jan 1, 2000, Greenwich time seems like a good candidate. http://www.naggum.no/lugm-time.html 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 year leap-year cycle. Regards, Gisle
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)
On Mon, Aug 14, 2000 at 06:13:13PM -, Perl6 RFC Librarian wrote: =head1 TITLE Maintain internal time in Modified Julian (not epoch) How would this be stored? As a floating point number? What about sub-second accuracy? To get seconds you'd need about 5.15 decimal places (let's just call that 6) I think it should be stored as 2 numbers, the julian day and the seconds into that day. Also, I'd bet that most people only use time() in conjunction with one of the other date/time routines to get hours/minutes/formatted time/formatted date/whatever. Will these other date-ish routines have to be modified to understand mjdate() output? -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)
How 'bout 100ns ticks from base date, stored in a 64-bit number? That We are going to have quads supported on all platforms, then? With software emulation of our own if nothing else is available? I wouldn't object, mind... -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)
On Mon, Aug 14, 2000 at 02:42:39PM -0400, Dan Sugalski wrote: At 01:36 PM 8/14/00 -0500, Jonathan Scott Duff wrote: On Mon, Aug 14, 2000 at 06:13:13PM -, Perl6 RFC Librarian wrote: =head1 TITLE Maintain internal time in Modified Julian (not epoch) How would this be stored? As a floating point number? What about sub-second accuracy? To get seconds you'd need about 5.15 decimal places (let's just call that 6) I think it should be stored as 2 numbers, the julian day and the seconds into that day. How 'bout 100ns ticks from base date, stored in a 64-bit number? That should see us into Y30K, assuming the integer is signed... Sure, but does that mean that perl will support 64-bit ints on all platforms? I think automagic type promotion to/from bigints would be great but it would swamp anyone doing lots of date/time calculations. I'm just guessing that manipulating time values is much more common than arithmetic with large numbers. Or will we have special purpose stages in between able-to-use-native and need-to-use-something-bigger, one of which could be 64-bit? -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)
At 01:48 PM 8/14/00 -0500, Jarkko Hietaniemi wrote: How 'bout 100ns ticks from base date, stored in a 64-bit number? That We are going to have quads supported on all platforms, then? With software emulation of our own if nothing else is available? I wouldn't object, mind... I'd like to provide ints of that size, yes. Whether they're native (on, say, Alphas or SPARCs), faked by the compiler, or faked by perl is an open question, but I would like them in. This might end up in BigInt format instead of plain int if the platform integers are too small, but that's OK, I think. 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)
On Mon, Aug 14, 2000 at 03:01:48PM -0400, Dan Sugalski wrote: 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 :-) We may have ints of various sizes. (Or we may make it look that way but really fake it... :) Hard to say yet. As long as it Just Works from the language level, I don't care how it's done :-) my $i = 100_000_000_000_000_000;# big number! $i += 100_000_000_000_000_000; # even bigger! print "$i\n"; # Oh my gosh, it worked! -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)
On Mon, 14 Aug 2000, Nick Ing-Simmons wrote: Jonathan Scott Duff [EMAIL PROTECTED] writes: On Mon, Aug 14, 2000 at 06:13:13PM -, Perl6 RFC Librarian wrote: =head1 TITLE Maintain internal time in Modified Julian (not epoch) There has to be _an_ epoch - even Caesar started somewhere... Julian Date is measured (roughly) from earliest astronomical observations that we have available to us. MJD is JD with the slowly varying bit removed (and correcting for the 0.5 day so that MJD starts at midnight rather than midday). How would this be stored? As a floating point number? What about sub-second accuracy? To get seconds you'd need about 5.15 decimal places (let's just call that 6) IEEE 'float' (the short one) has about 6 places (24 bit mantissa). double has many more. But even I don't think using years as the "unit" is right thing to do. Seconds is my favourite... Just to clarify, MJD is days not years. A 32-bit double preicision number is usually adequate -- although have not thought about nano seconds! -- 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)
On Mon, Aug 14, 2000 at 02:28:29PM -0500, Jonathan Scott Duff wrote: On Mon, Aug 14, 2000 at 03:01:48PM -0400, Dan Sugalski wrote: 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 :-) You think you've got problems... I saw "mjdate" and thought that Mark Jason Dominus was involved. But yes, this is an internals issue. K. -- Kirrily Robert -- [EMAIL PROTECTED] -- http://netizen.com.au/ Open Source development, consulting and solutions Level 10, 500 Collins St, Melbourne VIC 3000 Phone: +61 3 9614 0949 Fax: +61 3 9614 0948 Mobile: +61 410 664 994
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)
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::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.
snip
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?
In one of my previous posts I was simply suggesting that the Date object
(whatever it is) should have a method to return the internal format
(seconds, mjd, whatever) to allow for simple date arithmetic without
having to do anything more complicated. unix seconds and mjd both will
allow this.
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.
Of course, "seconds since 1970" is only obvious to unix systems
programmers. "Number of days since XXX" is just as valid for someone
coming to the language from a different direction and at least has some
kind of basis outside of computing.
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.
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.
In fact RFC #7 ("Higher Resolution time values") suggests that the
concept of "number of seconds since epoch" will have to make room for
fractions of a second anyway.
--
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)
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)
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. perlfunc states that time() returns seconds since machine epoch, noting that it varies from platform to platform. (As some have noted, the Mac epoch is in 1904. I think this is so you can divide the years since epoch by 4 and have the remainder indicate the leap-year condition. Wouldn't have worked for 1900, and most of us have probably dealt with that fact at some point, by now.) It might be advisable for portability concerns to standardize on an epoch. If so, this Mac user would vote for the UNIX epoch. It is simply the most widely accepted. I'm not sure what Windows does, but I thought I might have seen something that implied it was using (or at least converting to and from) UNIX epoch. Mac will probably use that epoch, anyway, once OS X comes out (which will fuse Mac OS and UNIX in what I expect will be a beautiful way). 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 kind of hoping Perl6 would formalize this into a black-box value, meaning an object, and offload everything into a standard module instead of the core. Kirrily and Dan, isn't it time for a time and date sublist? J. David
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. 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? -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
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)
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)
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/
