Re: Time::Local
On Aug 17, 2005, at 00:29 , Larry Wall wrote: which gives us these possibilities. 大務big / (perform) duty Perl6 to people here. 太夢fat, big / dream Perl6 for the rest of us. 対夢oppose, against, pair / dream Pugs? 待夢wait / dream Perl6 to Oreilly ? 滞夢stop, stagnate / dream Perl6 to kansai.pm :) All sounds pretty perl6 to me. Oh, be careful of this one. 台無stand, platform / not, none, cease to be Usually this one reads 'Dai-Nashi' (kun-yomi), meaning "to blow from grounds up". Dan the Man from a Place with Too Many Puns and Funs
Re: Time::Local
Well, right now one of the great things about looking at the wall to read the clock and see the time, is that you know that based on the time of day and the time of year, and where you are, roughly how far through the actual solar day it is. It's crude, but useful. Just ask a Dairy Farmer. Does the Dairy Farmer need time with seconds precision? Would he know his longitude and how to make correction to the time? (If he is a person, wouldn't it be easier for him just to buy GPS?) Of course feel free to consider this all worthless heckling, given the lack of time I've been putting towards an implementation of all this ;). Sam. Same here. Maybe this lengthy discussion isn't really that useful. I think it's about defaults, but Perl6 will have packages -- so everyone not content with the default handling of time will be able to override it. Or maybe there could be a pragma (`no leapseconds`?). Or maybe there could be a package on CP6AN named Time::Leapseconds::Data. Related question: is it possible to specify validity of a package? Something along the lines "this package starts to be deprecated/imprecise/outdated after 2007". braňo tichý
Re: Time::Local
On Wed, 2005-08-17 at 01:28 -0500, Dave Rolsky wrote: > > Why on earth would you want to encourage such a short sighted > > programming practise? The earth wobbles like a spinning top. In fact > It's hardly short sighted to want leap seconds to be abandoned (not in > Perl but world wide). The few people who _really_ care about syncing to > midnight can still have them, but the rest of the world would be just fine > with a leap hour every couple hundred years. Well, right now one of the great things about looking at the wall to read the clock and see the time, is that you know that based on the time of day and the time of year, and where you are, roughly how far through the actual solar day it is. It's crude, but useful. Just ask a Dairy Farmer. What else do you want the time of day to represent? You would prefer it something completely arbitrary, just to make it easier to program with? That we don't just use a straight solar clock is probably down to the fact that it was technically infeasible to have one without a sundial, which obviously doesn't work at night or in England. > > alternate times. Environments that really can't guarantee an absolute > > epoch can simply return unanchored times and let the modules throw > > exceptions when you try to convert them to real times or times with > > impossible levels of accuracy. > Great, so now code that works in one environment throws a "cannot find an > up-to-date leap seconds table" exception in another? Eek! Well, only if you try to do something silly like ask for the number of seconds between two points of time in different days a long time in the future, where those times were composed from Gregorian components. If you were to ask for the number of minutes, or not cross the boundary of when leap seconds are allowed, then it would still be OK. I would expect a similar exception if I tried to calculate the number of hours between two dates in an unknown timezone. Of course feel free to consider this all worthless heckling, given the lack of time I've been putting towards an implementation of all this ;). Sam.
Re: Time::Local
On Wed, 17 Aug 2005, Sam Vilain wrote: Why on earth would you want to encourage such a short sighted programming practise? The earth wobbles like a spinning top. In fact It's hardly short sighted to want leap seconds to be abandoned (not in Perl but world wide). The few people who _really_ care about syncing to midnight can still have them, but the rest of the world would be just fine with a leap hour every couple hundred years. synced, etc. Date modules (which, really, people should be using) then have something sensible to work with and can easily provide the alternate times. Environments that really can't guarantee an absolute epoch can simply return unanchored times and let the modules throw exceptions when you try to convert them to real times or times with impossible levels of accuracy. Great, so now code that works in one environment throws a "cannot find an up-to-date leap seconds table" exception in another? Eek! -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/
Re: Time::Local
On Mon, 2005-08-15 at 22:24 -0700, Larry Wall wrote: > : > That's my leaning--if I thought it might encourage the abandonment of > : > civil leap seconds, I'd be glad to nail it to Jan 1, 2000, 00:00:00.0 UTC. > : If we're going with TAI, can't we just nail it to the epoch it defines, > : instead? > Because I'm a megalomaniac, silly dilly. Plus I like round numbers. > Not to mention the fact that it makes it really easy to calculate days > since 2000, give or take a squishy leapsecond or three. > But the best part is that if we abandon UTC leap seconds for civil time, > we don't have to remember leap seconds going forward, only backward from > 2000. Why on earth would you want to encourage such a short sighted programming practise? The earth wobbles like a spinning top. In fact its speed increased after the two major Earthquakes in Antarctica and Indonesia last December. Subtle adjustments are necessary to track this; perhaps including the possibility that the Earth's rotational speed might change by more than one second per day. Just why were the Mayan, Babylonian and Aztec calendars 360 days long, anyway? Were days 20 minutes longer then? These are questions I've been wondering as an old machine I have loses about this amount ... it would certainly explain it if the machine was actually so old it used a Mayan timer chip. (Sometimes the impossible has a coherency to it that the merely improbable simply lacks...) How about killing the argument by saying the epoch is only guaranteed by the language to be relative to the same value within the lifetime of a script, relative to 0.0 TAI in 1958 or whenever it was. Then Perl 6 implementations are free to pick their own epoch, and possibly also annotate the time via traits/properties as not being confirmed to be NTP synced, etc. Date modules (which, really, people should be using) then have something sensible to work with and can easily provide the alternate times. Environments that really can't guarantee an absolute epoch can simply return unanchored times and let the modules throw exceptions when you try to convert them to real times or times with impossible levels of accuracy. Sam.
Re: Time::Local
On Tue, Aug 16, 2005 at 01:18:40PM -0400, Mark Reed wrote: : More generally, the numbers are quite reasonable. For example, for about 30 : years on either side of the epoch you have resolution to at least .1 : microsecond. And in 30 years we'll probably mostly be using 128 or 256-bit floaters... Larry
Re: Time::Local
On 2005-08-16 12:39, "Brano Tich‡" <[EMAIL PROTECTED]> wrote: > A related question: > I think it was stated, that the time will be some floating-point number. > Will its precision be predetermined or will it be system-dependent? > (Or maybe the precision is no-issue -- it could be important in comparisons, > but one can argue one should always specify the smallest unit when comparing > times. Only issues left are intervals; I vaguely remember something about > losing precision when subtracting two close floating-point numbers.) Floating point has the advantage of great range without great storage requirements; you can represent times far in the past or future, but the further away from time 0 you go, the less resolution you have. Which is usually perfect for real-life applications. For example, given a 64-bit IEEE double-precision floating point representation with 1-second units, you can represent time between points about 10^308 seconds (3x10^300 years) before and after the epoch - which is about 10^290 times the oldest estimates of the age of the universe. But at those extremes, the time *between* representable points is a whopping 2x10^292 seconds (6x10^284 years). At the other extreme, you have precision down to 1/10^308 of a second on either side of the epoch itself. More generally, the numbers are quite reasonable. For example, for about 30 years on either side of the epoch you have resolution to at least .1 microsecond.
Re: Time::Local
I vote for double-precision floating-point. Since double precision is good to 10^-15, that allows times to be specified to a precision of about 3 microseconds for the next century, and to a precision of 30 microseconds for the next millennium. Anyone who wants more precision than that is likely to have implemented his/her own library. Further, the trade between distance from the epoch and time resolution goes in the correct direction -- e.g. nobody wants microsecond precision when considering times 1,000,000 years in the past. Finally, floating point encapsulates nicely the practical nonexistence of simultaneity ( "$t1 == $t2" makes no sense without a measure of the allowed slop; integer times force an implied slop scale. ) On Aug 16, 2005, at 10:39 AM, Brano Tichý wrote: A related question: I think it was stated, that the time will be some floating-point number. Will its precision be predetermined or will it be system-dependent? (Or maybe the precision is no-issue -- it could be important in comparisons, but one can argue one should always specify the smallest unit when comparing times. Only issues left are intervals; I vaguely remember something about losing precision when subtracting two close floating-point numbers.) I ask because I stumbled across uuu time (http://www.unununium.org/ articles/uuutime) when I was looking for explanation of UTC/TAI/ *J*D et al. It is counted from 2000-01-01 TAI in microseconds and stored in signed 64 bit integer. brano
Re: Time::Local
A related question: I think it was stated, that the time will be some floating-point number. Will its precision be predetermined or will it be system-dependent? (Or maybe the precision is no-issue -- it could be important in comparisons, but one can argue one should always specify the smallest unit when comparing times. Only issues left are intervals; I vaguely remember something about losing precision when subtracting two close floating-point numbers.) I ask because I stumbled across uuu time (http://www.unununium.org/articles/uuutime) when I was looking for explanation of UTC/TAI/*J*D et al. It is counted from 2000-01-01 TAI in microseconds and stored in signed 64 bit integer. brano
Re: Time::Local
On Wed, 17 Aug 2005, Autrijus Tang wrote: ...This seems to be quite consistent with the rumoured US proposal to abolish leap seconds by adding leap hours every 500 years or so: Wow, a piece of US government policy I can actually support! Hell must be a cold place right now. -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/
Re: Time::Local
On Tue, Aug 16, 2005 at 08:37:24AM -0700, Larry Wall wrote: > : But that's in contrast to your saying that the epoch would be December 31, > : 1999 at 23:59:29.0 UTC. Or did I misread your earlier messages? > > Yes, you misread it. I was angling for 00:00:00.0 UTC. But it scarcely > matters if UTC keeps screwing around with leap seconds, and civil time > stays locked to UTC. I personally think we should add a bunch of leap > seconds at the beginning of every year divisible by 100, and leave the > rest of the years alone. ...This seems to be quite consistent with the rumoured US proposal to abolish leap seconds by adding leap hours every 500 years or so: http://www.post-gazette.com/pg/05210/545823.stm Ending leap seconds would make the sun start rising later and later by the clock -- a few seconds later each decade. To compensate, the U.S. has proposed adding in a "leap hour" every 500 to 600 years, which also accounts for the fact that the Earth's rotation is expected to slow down even further. That would be no more disruptive than the annual switch to daylight-saving time, said Ronald Beard of the Naval Research Laboratory, who chairs the ITU's special committee on leap seconds and favors their abolishment. "It's not like someone's going to be going to school at four in the afternoon or something," he said. Thanks, /Autrijus/ pgpsTEMTIuNi9.pgp Description: PGP signature
Re: Time::Local
On Tue, 16 Aug 2005, zowie wrote: Hmmm... at least backwards leap-seconds are fixed. Handling leap-seconds for all time requires net access or frequent software updates, but a single block of 32 comparisons handles everything up to A.D. 2000. Well, if you want accuracy you need to get that info one way or another, right? Although since most servers use NTP (or whatever MS uses), and that ultimately goes back to UTC from atomic clocks, you can always get an accurate local time (except _during_ leap a second when POSIX goes insane). Anyway, I don't think we should worry about this too much. There are a couple of ways to use epochs. One is to use it for sorting/comparison, like for file last mod times. In that case, the actual datetime the epoch represents is irrelevant. If you need to do anything with the actual datetime, I think it's best to turn it into some higher-level representation, like a date(time) object. The existing Time::Local bits in pugs are a reasonable start at a simple lightweight datetime class, and I'm hoping to be able to provide a more complete set of classes for date & time bits in the future. If we can encourage people to always use one of these, then hopefully most people will never need to care what Perl6's epoch actually _means_. It's just a magic number you pass to some function or library. -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/
Re: Time::Local
Hmmm... at least backwards leap-seconds are fixed. Handling leap- seconds for all time requires net access or frequent software updates, but a single block of 32 comparisons handles everything up to A.D. 2000. On Aug 16, 2005, at 9:24 AM, Dave Rolsky wrote: On Mon, 15 Aug 2005, Larry Wall wrote: But the best part is that if we abandon UTC leap seconds for civil time, we don't have to remember leap seconds going forward, only backward from 2000. So you want to take on the (very irritating, I tell you) burden of leap seconds going _backwards_ but not going forwards? But that's in contrast to your saying that the epoch would be December 31, 1999 at 23:59:29.0 UTC. Or did I misread your earlier messages? -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/
Re: Time::Local
On Tue, Aug 16, 2005 at 10:24:41AM -0500, Dave Rolsky wrote: : On Mon, 15 Aug 2005, Larry Wall wrote: : : >But the best part is that if we abandon UTC leap seconds for civil time, : >we don't have to remember leap seconds going forward, only backward from : >2000. : : So you want to take on the (very irritating, I tell you) burden of leap : seconds going _backwards_ but not going forwards? Well, sure, but we have no choice about the ones that were already performed. We could certainly take on the burden of tracking leap seconds in the future as well, but my point is we don't know them in advance. The old ones stay put, but the new ones potentially change from year to year. (Though they might not, if we get rid of civil leap seconds.) : But that's in contrast to your saying that the epoch would be December 31, : 1999 at 23:59:29.0 UTC. Or did I misread your earlier messages? Yes, you misread it. I was angling for 00:00:00.0 UTC. But it scarcely matters if UTC keeps screwing around with leap seconds, and civil time stays locked to UTC. I personally think we should add a bunch of leap seconds at the beginning of every year divisible by 100, and leave the rest of the years alone. Larry
Re: Time::Local
On Mon, Aug 15, 2005 at 09:21:14PM -0400, Jasmine Pues wrote:
: Taimu? TAI- -mu.
:
: Sorry. Couldn't resist the pun. (Bad Japanese pun, but nonetheless.)
Well, hmm, yes, "taimu" means "time" in Japanese, but only because it's
borrowed... ☺
On the other hand, if you're willing to coin a new Japanese word,
we can generate all the combinations of Jouyou Kanji that can be
pronounced "TAI MU" and see what they mean together:
#!/usr/bin/perl
use utf8;
binmode STDIN, ":utf8";
binmode STDOUT, ":utf8";
binmode STDERR, ":utf8";
@tai = split /^/, <<'END';
大 big
太 fat, big
体 body; health
台 stand, platform
対 oppose, against, pair
待 wait
代 replace, world, generation, fee
帯 belt, obi, wear, zone
隊 corps, unit
退 retreat, withdraw
貸 lend, loan
態 appearance, intent
耐 endure, bear
怠 be lazy, neglect
胎 womb
泰 calm, serene, big, thai
袋 bag, pouch
逮 chase, seize
替 exchange, swap
滞 stop, stagnate
END
@mu = split /^/, <<'END';
武 military, warrior
務 (perform) duty
無 not, none, cease to be
謀 plot, strategem
矛 halberd, lance, spear
夢 dream
霧 mist, fog
END
chomp @tai;
chomp @mu;
for my $tai (@tai) {
($tk, $te) = split(' ', $tai, 2);
for my $mu (@mu) {
($mk, $me) = split(' ', $mu, 2);
printf "%s%s%s / %s\n", $tk,$mk, $te, $me;
}
}
which gives us these possibilities.
大武 big / military, warrior
大務 big / (perform) duty
大無 big / not, none, cease to be
大謀 big / plot, strategem
大矛 big / halberd, lance, spear
大夢 big / dream
大霧 big / mist, fog
太武 fat, big / military, warrior
太務 fat, big / (perform) duty
太無 fat, big / not, none, cease to be
太謀 fat, big / plot, strategem
太矛 fat, big / halberd, lance, spear
太夢 fat, big / dream
太霧 fat, big / mist, fog
体武 body; health / military, warrior
体務 body; health / (perform) duty
体無 body; health / not, none, cease to be
体謀 body; health / plot, strategem
体矛 body; health / halberd, lance, spear
体夢 body; health / dream
体霧 body; health / mist, fog
台武 stand, platform / military, warrior
台務 stand, platform / (perform) duty
台無 stand, platform / not, none, cease to be
台謀 stand, platform / plot, strategem
台矛 stand, platform / halberd, lance, spear
台夢 stand, platform / dream
台霧 stand, platform / mist, fog
対武 oppose, against, pair / military, warrior
対務 oppose, against, pair / (perform) duty
対無 oppose, against, pair / not, none, cease to be
対謀 oppose, against, pair / plot, strategem
対矛 oppose, against, pair / halberd, lance, spear
対夢 oppose, against, pair / dream
対霧 oppose, against, pair / mist, fog
待武 wait / military, warrior
待務 wait / (perform) duty
待無 wait / not, none, cease to be
待謀 wait / plot, strategem
待矛 wait / halberd, lance, spear
待夢 wait / dream
待霧 wait / mist, fog
代武 replace, world, generation, fee / military, warrior
代務 replace, world, generation, fee / (perform) duty
代無 replace, world, generation, fee / not, none, cease to be
代謀 replace, world, generation, fee / plot, strategem
代矛 replace, world, generation, fee / halberd, lance, spear
代夢 replace, world, generation, fee / dream
代霧 replace, world, generation, fee / mist, fog
帯武 belt, obi, wear, zone / military, warrior
帯務 belt, obi, wear, zone / (perform) duty
帯無 belt, obi, wear, zone / not, none, cease to be
帯謀 belt, obi, wear, zone / plot, strategem
帯矛 belt, obi, wear, zone / halberd, lance, spear
帯夢 belt, obi, wear, zone / dream
帯霧 belt, obi, wear, zone / mist, fog
隊武 corps, unit / military, warrior
隊務 corps, unit / (perform) duty
隊無 corps, unit / not, none, cease to be
隊謀 corps, unit / plot, strategem
隊矛 corps, unit / halberd, lance, spear
隊夢 corps, unit / dream
隊霧 corps, unit / mist, fog
退武 retreat, withdraw / military, warrior
退務 retreat, withdraw / (perform) duty
退無 retreat, withdraw / not, none, cease to be
退謀 retreat, withdraw / plot, strategem
退矛 retreat, withdraw / halberd, lance, spear
退夢 retreat, withdraw / dream
退霧 retreat, withdraw / mist, fog
貸武 lend, loan / military, warrior
貸務 lend, loan / (perform) duty
貸無 lend, loan / not, none, cease to be
貸謀 lend, loan / plot, strategem
貸矛 lend, loan / halberd, lance, spear
貸夢 lend, loan / dream
貸霧 lend, loan / mist, fog
態武 appearance, intent / military, warrior
態務 appearance, intent / (perform) duty
態無 appearance, intent / not, none, cease to be
態謀 appearance, intent / plot, strategem
態矛 appearance, intent / halberd, lance, spear
態夢 appearance, intent / dream
態霧 appearance, intent / mist, fog
耐武 endure, be
Re: Time::Local
On Mon, 15 Aug 2005, Larry Wall wrote: But the best part is that if we abandon UTC leap seconds for civil time, we don't have to remember leap seconds going forward, only backward from 2000. So you want to take on the (very irritating, I tell you) burden of leap seconds going _backwards_ but not going forwards? But that's in contrast to your saying that the epoch would be December 31, 1999 at 23:59:29.0 UTC. Or did I misread your earlier messages? -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/
Re: Time::Local
Taimu? TAI- -mu. Sorry. Couldn't resist the pun. (Bad Japanese pun, but nonetheless.) -Jasmine 2005/8/15, Sam Vilain <[EMAIL PROTECTED]>: > On Mon, 2005-08-15 at 16:33 -0700, Larry Wall wrote: > > : I would assume that you would choose time 0.0 = Jan 1, 2000 at 00:00:00.0 > > : TAI (December 31, 1999 at 23:59:29.0 UTC), making the whole thing free of > > : any UTC interferences. But there is an argument for making the zero > > point a > > : recognizable boundary in civil time. > > That's my leaning--if I thought it might encourage the abandonment of > > civil leap seconds, I'd be glad to nail it to Jan 1, 2000, 00:00:00.0 UTC. > > If we're going with TAI, can't we just nail it to the epoch it defines, > instead? > > Sam. > > -- "Don't presume to lecture me about good and evil. I've been there, you've just seen a map." -Orson Scott Card -- http://www.spreadfirefox.com
Re: Time::Local
On Tue, Aug 16, 2005 at 01:18:58PM +1200, Sam Vilain wrote: : On Mon, 2005-08-15 at 16:33 -0700, Larry Wall wrote: : > : I would assume that you would choose time 0.0 = Jan 1, 2000 at 00:00:00.0 : > : TAI (December 31, 1999 at 23:59:29.0 UTC), making the whole thing free of : > : any UTC interferences. But there is an argument for making the zero point a : > : recognizable boundary in civil time. : > That's my leaning--if I thought it might encourage the abandonment of : > civil leap seconds, I'd be glad to nail it to Jan 1, 2000, 00:00:00.0 UTC. : : If we're going with TAI, can't we just nail it to the epoch it defines, : instead? Because I'm a megalomaniac, silly dilly. Plus I like round numbers. Not to mention the fact that it makes it really easy to calculate days since 2000, give or take a squishy leapsecond or three. But the best part is that if we abandon UTC leap seconds for civil time, we don't have to remember leap seconds going forward, only backward from 2000. But mostly because I'm a megalomaniac, and think I can change the world. Larry
Re: Time::Local
On Mon, 2005-08-15 at 16:33 -0700, Larry Wall wrote: > : I would assume that you would choose time 0.0 = Jan 1, 2000 at 00:00:00.0 > : TAI (December 31, 1999 at 23:59:29.0 UTC), making the whole thing free of > : any UTC interferences. But there is an argument for making the zero point a > : recognizable boundary in civil time. > That's my leaning--if I thought it might encourage the abandonment of > civil leap seconds, I'd be glad to nail it to Jan 1, 2000, 00:00:00.0 UTC. If we're going with TAI, can't we just nail it to the epoch it defines, instead? Sam.
Re: Time::Local
On Mon, Aug 15, 2005 at 04:41:03PM -0400, Mark Reed wrote: : On 2005-08-15 13:56, "Larry Wall" <[EMAIL PROTECTED]> wrote: : > Perl 6 will natively think of dates as number of floating point TAI : > seconds from the year 2000. You can build any kind of date interface : > on top of that, but we're going for simplicity and predictability. : : I applaud that decision. I just have one question: will the zero point be : chosen according to TAI or UTC? : : I would assume that you would choose time 0.0 = Jan 1, 2000 at 00:00:00.0 : TAI (December 31, 1999 at 23:59:29.0 UTC), making the whole thing free of : any UTC interferences. But there is an argument for making the zero point a : recognizable boundary in civil time. That's my leaning--if I thought it might encourage the abandonment of civil leap seconds, I'd be glad to nail it to Jan 1, 2000, 00:00:00.0 UTC. Larry
Re: Time::Local
On 2005-08-15 13:56, "Larry Wall" <[EMAIL PROTECTED]> wrote: > Perl 6 will natively think of dates as number of floating point TAI > seconds from the year 2000. You can build any kind of date interface > on top of that, but we're going for simplicity and predictability. I applaud that decision. I just have one question: will the zero point be chosen according to TAI or UTC? I would assume that you would choose time 0.0 = Jan 1, 2000 at 00:00:00.0 TAI (December 31, 1999 at 23:59:29.0 UTC), making the whole thing free of any UTC interferences. But there is an argument for making the zero point a recognizable boundary in civil time. The Olson library does that (its zero point is 00:00:10.0 TAI on Jan 1, 1970), but that's only because it's designed to be a drop-in replacement for the standard POSIX library and the time_t values have to match. Since you're changing the epoch, there's no compatibility constraint here . . .
Re: Time::Local
On 2005-08-15 13:56, "Larry Wall" <[EMAIL PROTECTED]> wrote: > I'm personally rooting for everyone to abandon leap seconds for civil time. While you're at it, why not wish for DST to go away (or to become permanent year-round, whichever)? Heck, toss in world peace, too. :) > But POSIX stretchy seconds must die. So Say We All.
Re: Time::Local
On 2005-08-15 15:04, "Doug McNutt" <[EMAIL PROTECTED]> wrote: > At 13:31 -0400 8/15/05, Mark Reed wrote: > If anyone gets serious about Julian dates there is also the Modified Julian > Date, MJD, used by the US military and others. It differs from the JAD above > by a large well-defined integer plus 1/2. The (then) most recent even multiple of 100,000 was chosen for it: MJD 0 = JD 2,400,000.5. > The result is a day that begins at > midnight and starts at a more recent date that I don't remember. It's not Jan > 0, 1970 though. November 17, 1858. Which, while not Jan 1, 1970, is still time zero for another operating system some of you may have heard of: VMS. There's also something called the Truncated Julian Day/Date, or TJD, which NASA used to use: it was essentially the last four digits of the MJD, so that TJD 0 was MJD 4, aka May 24, 1968. But once MJD 5 rolled around (on Oct 10, 1995), the TJD became ambiguous. Besides, while saving a decimal digit of storage per log entry was significant when NASA was trying to get computers light enough to launch in the 1960s, it's not exactly an earth-shattering storage win today. So the TJD is best avoided. In fact, forget I mentioned it. :)
Re: Time::Local
Perl 6 will natively think of dates as number of floating point TAI seconds from the year 2000. You can build any kind of date interface on top of that, but we're going for simplicity and predictability. If UTC goes ahead with with additional leap seconds, we will NOT use Posix stretchy seconds to represent them. I'm personally rooting for everyone to abandon leap seconds for civil time. Civil leap adjustments really ought to be scheduled more than six months in advance. Once a century would be about right. But POSIX stretchy seconds must die. Larry
Re: Time::Local
At 13:31 -0400 8/15/05, Mark Reed wrote: >More specifically, that's the astronomical Julian Day, or JD, and JD 0 began >at noon Universal Time (a.k.a. GMT) on January 1, 4713 BC in the Julian >calendar. Sometimes this is called the Julian Astronomical Day, or JAD, to >distinguish it from various other misappropriations of the term "julian >day/date". If anyone gets serious about Julian dates there is also the Modified Julian Date, MJD, used by the US military and others. It differs from the JAD above by a large well-defined integer plus 1/2. The result is a day that begins at midnight and starts at a more recent date that I don't remember. It's not Jan 0, 1970 though. There is also ephemeris time which is the absolute clock that makes Newtonian mechanics come out correctly regardless of changes in the rotational speed of planet Earth. Don't even think about supporting that. -- --> Halloween == Oct 31 == Dec 25 == Christmas <--
Re: Time::Local
On 2005-08-15 13:07, "Mark A. Biggar" <[EMAIL PROTECTED]> wrote: > 3) use Astronomical Dates which are kept as the number of days sense > noon Jan-1-4713 BC. More specifically, that's the astronomical Julian Day, or JD, and JD 0 began at noon Universal Time (a.k.a. GMT) on January 1, 4713 BC in the Julian calendar. Sometimes this is called the Julian Astronomical Day, or JAD, to distinguish it from various other misappropriations of the term "julian day/date". More generally, astronomers use the Gregorian calendar like the rest of us, but often extend it into the past before its adoption, ignoring the Julian calendar switchover. They also tend to use 0 and negative years AD/CE in lieu of BC(E) numbering. On that basis, JD 0 began at noon on Nov 24, -4713. Julian Days make a good neutral format for storing dates (and, with fractional components, times), but they are a bit cumbersome. If you don't actually need the range they provide (because you're only dealing with dates near the present), it might be regarded as overkill to store the current time as e.g. 2453598.225995. In order to get 1-second resolution, the JD requires the same number of significant figures that's required to get millisecond resolution with time_t.
Re: Time::Local
Nicholas Clark wrote: On Tue, Jul 05, 2005 at 06:47:41PM -0600, zowie wrote: There is also a certain joy that comes from noticing that a tool was designed by pedants: it's great that cal(1) handles the Gregorian reformation correctly (or at least, in one of several arguably correct ways) even though most of us don't deal with dates in 1752. I disagree: $ LC_ALL=es_ES cal 9 1752 septiembre de 1752 do lu ma mi ju vi sá 1 2 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 Spain adopted the Gregorian Calendar in 1582. Surely setting my locale to Spain should make the Julian/Gregorian jump show up in 1582, not 1752? I think that this demonstrates how tricky all this mess is. Nicholas Clark The actual situation is even worse. You can even use Gregorian dates for all of 20th history as Russia didn't convert from Julian until 1920. There is not much you can do to simply store historical dates on a computer: 1) keap all dates Gregoian even those before 1582 when the Gregorian calendar was first used by Catholic Europe. This was right in the middle of King Henry VIII's disagreement with the Catholic church so England didn't convert until 1752 (the cal refernce above). Given that Englands colonies converted at the same time this explains the confusion over the Washington's birthday holiday where some states used Feb 11 (Julian Calendar) and some used Feb 22 (Gregorian calendar), as Feb 12 is Lincon's Birthday, for the national version of the holiday it was decided to just call some Monday in Feb President's Day and do it all the same day. Also, do you use a year 0 or not, which is an interesting problem? 2) keep all dates as the people at that place and time in history would have recorded them, but that is hard as you loose comparability and lots of recorded historic date are Reign dated or things like N years sence the founding of Rome, etc. 3) use Astronomical Dates which are kept as the number of days sense noon Jan-1-4713 BC. 4) keep soe dates Julian Calandar and some Gregorian, but which switch over do you use. -- [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Time::Local
On 2005-08-15 10:07, "Nicholas Clark" <[EMAIL PROTECTED]> wrote: > Spain adopted the Gregorian Calendar in 1582. Surely setting my locale to > Spain should make the Julian/Gregorian jump show up in 1582, not 1752? Arguably so, but I don't think there's anywhere in the POSIX localization data structures to store that information. There's a huge variety of adoption dates, from Oct 5/15, 1582 (Most Catholic countries of Western Europe) to March 10/23, 1924 (Greek civil usage). Plus, even within its limited US/historical UK application, the cal(1) program is still (admittedly so on its own man page) inaccurate for dates prior to 1751, because it uses January 1 as the first day of the year. While that was true in the original design of the calendar as instituted by Caesar in 45 BC, and has been true in England and her colonies since 1751, at some point way back when England had started counting the year change on March 25. That was a gradual change with no clear transition date, so matching historical practice exactly is pretty much impossible for a large chunk of Isle history.
Re: Time::Local
On Tue, Jul 05, 2005 at 06:47:41PM -0600, zowie wrote: > There is also a certain joy that comes from noticing that a tool was > designed by pedants: > it's great that cal(1) handles the Gregorian reformation correctly > (or at least, in one > of several arguably correct ways) even though most of us don't deal > with dates in 1752. I disagree: $ LC_ALL=es_ES cal 9 1752 septiembre de 1752 do lu ma mi ju vi sá 1 2 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 Spain adopted the Gregorian Calendar in 1582. Surely setting my locale to Spain should make the Julian/Gregorian jump show up in 1582, not 1752? I think that this demonstrates how tricky all this mess is. Nicholas Clark
Re: Time::Local
On Wed, 6 Jul 2005, Juerd wrote: I think the problem one has is much bigger even if a day *number* is ever displayed. Then beginning with 1 because that's where most humans begin counting, is wrong. It's a technical thing, and that should be kept as simple as possible, and as technical as possible, for easier compatibility with existing technical things. Calling Sunday 1 and not having a 0 would certainly upset and offend me. My weeks begin on Mondays, as do most people's weeks here. At the same time, I can accept any day as the first day if that first day is 0, because 0 is technical and internal anyway, not meant for humans. I'm sure lots of people would want an index 1 to be Sunday, if there is no index 0. This all is solved simply by NOT skipping 0, and using an arbitrarily chosen day for the first. Or, well, for compatibility, Sunday :) Computers and Perl count from 0. People count from 1. If something begins at 1, it is expected to be a people's thing. And with week days, this just doesn't work, as not everyone's week starts at the same day. On reflection, I realized it doesn't matter too much to me. In the end, I'm likely to need a higher-level interface than this to do something interesting (like print a day _name_ or calculate the second Sunday of the month) and that interface will just use the information Perl's builtins give it. -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/
Re: Time::Local
Juerd wrote: I think the problem one has is much bigger even if a day *number* is ever displayed. Then beginning with 1 because that's where most humans begin counting, is wrong. It's a technical thing, and that should be kept as simple as possible, and as technical as possible, for easier compatibility with existing technical things. As a technical remark I like to point out, that you need 8 time points to define 7 days. Every day is bounded by two such time points---which are of course 24 hours apart. This is necessary to get the arithmetic right! Weekday arithmetic is modulo 7. Or put differently $week.end() - $week.start() == $week.length == 7 days must hold. If e.g. you start your week with Monday than this becomes $Sunday.end() - $Monday.start() == 7 days. The next order of precision in calender arithmetic is the hour *within* the day, then minutes and seconds. The weeks themselfs are subdivisions of years. And the scheme is not completely regular in e.g. the Gregorian calendar---but almost e.g in the Sym454 calendar which only has leap weeks. I think, that this type of integer with remainder arithmetic shows up in Perl6 in other places as well. E.g. chars in strings depending on the Unicode level and index arithmetic of arrays. Some unification of the underlying math would be nice, indeed. And that typically involves starting from 0 and the positive remainder pointing into the day. Regards, -- TSa (Thomas Sandlaß)
Re: Time::Local -- and lexical scope
On Tue, Jul 05, 2005 at 03:48:47PM -0700, Dave Whipp wrote:
: Dave Whipp wrote:
:
: >You can use "{time - $epoch}" or "{time.as<%d>}" or "{int time}". (That
: >last one is not "{+time}", because that would be a floating-point value,
: >not an integer).
Or {time.int}, presumably.
: I was thinking: an epoch is just a time, and "int time" is a duration --
: the number of seconds since the current epoch. So, the following should
: work:
:
: for 1 .. 2 -> {
:use epoch time();
:sleep 6;
:say int time;
: }
:
: This should print something close to "6", twice.
:
: But something niggled me: does the value of the RHS of a "use" get
: evaluated at run time, or compile time? In perl5, that could definitely
: would only execute the C once.
I would not necessarily assume that "use" is the best interface for
setting what is essentially a lexically scoped variable.
: I could see 3 possible behaviors:
:
: 1. C sets the epoch for each iteration of the loop, thus calling
: time() one per iteration
The pragma could arrange to install something in the runtime code
at that point, but it would take extraordinary measures and be
completely unexpected.
: 2. C executes just once, at compile time. Thus seconds iteration
: prints approximately "12"
Or much more than that, given separate compilation.
: 3. C does a compile-time binding of the epoch to the time()
: function. So each iteration prints "0".
: Which actually happens?
Am I allowed to vote for none of the above? :-)
Actually what should happen is most like 2, I suspect.
Coming at it from a different angle, I'm thinking we should try to
get rid of built-in none-ary functions like time anyway, and parse them
to expect an argument, on the assumption that this will simplify
MMD. (In fact, that's a good reason to get rid of the entire
"named unary" precedence level and treat them all as list operators
for parsing purposes.) So if we're allowing an optional argument
to time(), then it makes sense to allow time($epoch), where time
can default to a particular epoch, or even to the epoch defined in
the caller's lexical scope. I'd like time(2000) to be the standard
default, but time(1958) shouldn't be too hard to arrange.
We could set that default pragmatically, but pragmatically speaking,
we should just set the epoch as a lexical variable that is visible
to the default value for the parameter. Then the caller can
even do something like:
temp $_epoch_ = 1970;
$x = time();# sub time (?$epoch = $CALLER::_epoch_)
I'm not suggesting that's the proper name for the lexical variable.
In fact, we haven't got any convention for forced-lexicals in Perl
6 yet, other than, $_ and $/ are two examples of them, and $?FOO is
a compile-time lexical, and $=FOO is file-scoped in some fashion.
At one point I was thinking $*FOO would let the variable itself
decide if it was lexical or global, on the assumption that $_ is just
short for $*_. But maybe that's a Bad Idea. How do we decide which
variables are forced lexicals? More specifically, how to we request
the compiler to force other variables to be lexical, and poke them
into our lexical pads automatically for us? I think the epoch is
one of those, however we spell it. Then different modules can run
with different epochs, as long as all absolute times are passed
as objects.
Larry
Re: Time::Local
On Tue, Jul 05, 2005 at 06:47:41PM -0600, zowie wrote: : Hmmm Actually, ntpd achieves that sort of accuracy -- but if : I understand correctly it anchors the UTC time to the standard, : and allows the UNIX seconds count (which often does not account for : new leap seconds, though some gmtime versions account for old ones) : to drift or jump whenever a leap second goes by. The problem is : then that interval calculations that include the leap second are off : by one second. That probably doesn't bother most people but is an : endless cause of hassle in scientific applications. I think it would be wonderful to anchor our internal time to atomic time, even if our epoch isn't 1958. It's more important for our seconds to stay accurate than our timestamps, and we can make the approximate interfaces do the right thing if they know they're supposed to be approximate. The only problem is that we don't actually have atomic time available to most of our computers right now. Eventually we will, and I think it would be wonderful if were ready for that transition when it happens. Maybe even to the extent of pretending to be TAI-based by default even if we're not yet. We'll be wrong part of the time regardless of which way we pick. But I really, really wish UTC hadn't decided to add a leap second this year. It really wouldn't have hurt many folks to let midnight drift a few seconds and then do a major seconds correction at the end of the century, say. And it would have solved a lot of other problems. Oh well... : So, er, I guess I'm arguing that time/date stamps, if kept in numeric : counting-ticks form, should follow TAI in some easily definable way, : which probably means keeping track of leap seconds in a table that : can be updated easily. Even if the only interface most people use : is through UTC or civil time via the equivalent of gmtime (), IWBNI : the underlying engines knew enough to work well for those people : who do care about representing time at such high precision that leap : seconds matter. If the code is implemented with enough care to do : that right, then the natural epoch to use is probably 1958, though : as you pointed out the epoch itself is much less important than the : decision about what kind of time to track. I agree. time(2000) - time(1958) should just be a TAI constant. (Actually, it's a constant in UTC as well--it's just the POSIXly view of time that must die eventually. Slewing the clock for leap seconds is Just Wrong, and someday we'll fix it. Let's design with the assumption it will be fixed someday.) Larry
Re: Time::Local
On Jul 5, 2005, at 6:18 PM, Sam Vilain wrote: Craig DeForest wrote: Using the TAI epoch of 1958-01-01 00:00:00 has several advantages: - TAI is recognized by international standards-setting bodies (BIPM). - Perl6 will then shake out the 31-bit time rollover a full 12 years before ... I like this in principle, however I wonder of the merits of professing to return something of more accuracy than can actually ever be realistically assured from any of the platforms Perl runs. Hmmm Actually, ntpd achieves that sort of accuracy -- but if I understand correctly it anchors the UTC time to the standard, and allows the UNIX seconds count (which often does not account for new leap seconds, though some gmtime versions account for old ones) to drift or jump whenever a leap second goes by. The problem is then that interval calculations that include the leap second are off by one second. That probably doesn't bother most people but is an endless cause of hassle in scientific applications. There is also a certain joy that comes from noticing that a tool was designed by pedants: it's great that cal(1) handles the Gregorian reformation correctly (or at least, in one of several arguably correct ways) even though most of us don't deal with dates in 1752. So, er, I guess I'm arguing that time/date stamps, if kept in numeric counting-ticks form, should follow TAI in some easily definable way, which probably means keeping track of leap seconds in a table that can be updated easily. Even if the only interface most people use is through UTC or civil time via the equivalent of gmtime (), IWBNI the underlying engines knew enough to work well for those people who do care about representing time at such high precision that leap seconds matter. If the code is implemented with enough care to do that right, then the natural epoch to use is probably 1958, though as you pointed out the epoch itself is much less important than the decision about what kind of time to track. Cheers, Craig
Re: Time::Local
Craig DeForest wrote: Using the TAI epoch of 1958-01-01 00:00:00 has several advantages: - TAI is recognized by international standards-setting bodies (BIPM). - Perl6 will then shake out the 31-bit time rollover a full 12 years before I like this in principle, however I wonder of the merits of professing to return something of more accuracy than can actually ever be realistically assured from any of the platforms Perl runs. For a start, to convert from the available time source - the system clock - to TAI, you need to know; a) current adjustments, or when the lack of adjustments is considered valid up to (after that date, of course, if the list of adjustments is not updated, getting the time or converting from a time to a date on a calendar is an exception). b) whether or not the system clock is automatically correcting for leap seconds, ie when ntpd is running and sync'ed up. In any case, I'll add "to_TAI" as one of the marshalling methods for Date objects in Date.pm I guess it comes down to what guarantees we decide to make on the nature of time(). If a leap second passes while the script is running, can the value returned by time() regress? In fact, do we even need a fixed epoch? Why not just free-wheel it and make 0 the time the script started, get it to count seconds, and let interfaces for the system clock / orson database solve the hard problems. Sam.
Re: Time::Local
Dave Rolsky skribis 2005-07-05 15:41 (-0500): > As for 0 vs 1 as the index, I think this is a bit of a red herring. If > you're constantly using this as an array index you're operating at too low > a level (IMO). If all your programs start with: > my @DayNames = qw( Sunday Monday Tuesday ... ); > I think you have a bigger problem than simply adjusting for a 1-indexed > day number ;) I think the problem one has is much bigger even if a day *number* is ever displayed. Then beginning with 1 because that's where most humans begin counting, is wrong. It's a technical thing, and that should be kept as simple as possible, and as technical as possible, for easier compatibility with existing technical things. Calling Sunday 1 and not having a 0 would certainly upset and offend me. My weeks begin on Mondays, as do most people's weeks here. At the same time, I can accept any day as the first day if that first day is 0, because 0 is technical and internal anyway, not meant for humans. I'm sure lots of people would want an index 1 to be Sunday, if there is no index 0. This all is solved simply by NOT skipping 0, and using an arbitrarily chosen day for the first. Or, well, for compatibility, Sunday :) Computers and Perl count from 0. People count from 1. If something begins at 1, it is expected to be a people's thing. And with week days, this just doesn't work, as not everyone's week starts at the same day. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Time::Local
On Tue, 5 Jul 2005, Juerd wrote: No. Humans don't USE numbers for week days! So beginning at 1 makes no sense, except for humans who like creating lists like (undef, ). In fact, I would prefer to not having any 0 :) This should be separated into day() and day_name(). It's hardly obvious that day() should return a string, much less a bit of English! As for 0 vs 1 as the index, I think this is a bit of a red herring. If you're constantly using this as an array index you're operating at too low a level (IMO). If all your programs start with: my @DayNames = qw( Sunday Monday Tuesday ... ); I think you have a bigger problem than simply adjusting for a 1-indexed day number ;) -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/
Re: Time::Local
Darren Duncan wrote: Actually, there was a big oversight in my last message. It does not handle approximate or relative dates, such as when you don't know the details. FWIW, this is handled by DateTime::Incomplete, and also will be natively supported by Date::Gregorian. You're describing with this and other messages very much how the `Date' distribution in pugs is being designed. I'd very much appreciate input on that interface. Sam.
Re: Time::Local
At 3:36 PM -0700 7/5/05, Dave Whipp wrote: Darren Duncan wrote: The object should not store anything other than this single numerical value internally (smart caching of conversions aside). I think we can all either agree with that, or dont-care it. The internal implementation is an implementation issue (or library). It doesn't need to be defined by the language. The one important thing is that that language shouldn't define semantics that require more than this single value (e.g. we shouldn't associate the epoch with the object). What I'm saying is that the epoch for a high-precision-knowledge date is effectively hard-coded into Perl as a "standard" and users do not specify it or override it at any time. If this is accepted, then all that's left to discuss for these types of dates is what list of conversion methods there are and accepted input/output formats. Which perhaps is the point. The main reason implementation would have a say is if Perl's built-in functions do not return the Date/Time object, but some scalar information instead like Perl 5. But I say it should return the object. -- Darren Duncan
Re: Time::Local
Quoth Craig DeForest on Tuesday 05 July 2005 04:59 pm, > ...This is important > because, without proper maintenance of the leap-second table, all of our > perl6 calendar programs will run an hour late a mere 500 years from now. Uh, sorry -- "...an hour fast a mere 500 years from now."
Re: Time::Local
Quoth Darren Duncan on Tuesday 05 July 2005 04:20 pm, > I believe that at its core [the time/date] object should simply store a count of > rigorously defined time units relative to a rigorously defined epoch. > What the epoch is and what the time unit is will need to be > officially defined (eg, Jan 1, 2000; counting in fractions of > seconds). The object should not store anything other than this > single numerical value internally (smart caching of conversions > aside). Agree agree... Hmmm Straight seconds-counting has the flavor of international atomic time (TAI) to it, which suggests using the TAI (rather than UNIX) epoch. Using the TAI epoch of 1958-01-01 00:00:00 has several advantages: - TAI is recognized by international standards-setting bodies (BIPM). - Perl6 will then shake out the 31-bit time rollover a full 12 years before the rest of the UNIX-speaking world. :-) - TAI is sufficiently different from UNIX time to make implementors think carefully about their time conversion software. This is important because some UNIX implementations handle leap-seconds and others don't, and this is a nice chance to get everything Right the first time. - TAI-to-UT conversion modules can easily ingest leap-second announcements without further conversion to a different time base (see, e.g., ftp://62.161.69.5/pub/tai/publication/leaptab.txt). This is important because, without proper maintenance of the leap-second table, all of our perl6 calendar programs will run an hour late a mere 500 years from now.
Re: Time::Local
Actually, there was a big oversight in my last message. It does not handle approximate or relative dates, such as when you don't know the details. My previous proposal should be restricted specifically to the situations where you know the date/time to a high precision, to the second. So my previous proposal would still work for general tasks where the date/time you are storing in the object is generated by a clock, such as the computer's clock or a network time server etc, and is perfectly appropriate for what Perl's built-in "get current date/time" returns. I should also clarify that when I say "rigorously defined epoch", that also specifies a location (such as, "Jan 1, 2000, at Greenwich (sp?)"). Any mess related to time zones would be accounted for only during any calendar conversion used for storage or retrieval. For the other side, where the dates are imprecise, it actually would be useful to store them internally in calendar specific and human terms, basically matching whatever the source was. For example, you would store a date/time like "early May of 1743" this way; if all you know is that the date was in "early May", then what you're storing is fully accurate. Shoe-horning this into a specific day etc just for storage makes the data less accurate because someone reading the storage value presumes we knew for sure it was that day etc when in fact we didn't. Another example of an imprecise and relative date is "in the 4th year of Xerxes reign". If you didn't know when on our calendar that Xerxes ruled, you can't exactly convert this to a Gregorian calendar; you must store it in the terms that I mentioned for highest accuracy. Now of course, for such imprecise things, the simplest storage method is to just use a character string. Where it gets more complicated is if you want to do math or calculations with this imprecise info; that's one place that date/time such modules would really be useful and have their work cut for them. BTW, my main programming project (unreleased) is a genealogy/history/anything database type application, of an unprecedented focus and feature set, so I've thought a lot about these sorts of issues for being the most accurate and trustworthy possible. -- Darren Duncan
Re: Time::Local -- and lexical scope
Dave Whipp wrote:
You can use "{time - $epoch}" or "{time.as<%d>}" or "{int time}". (That
last one is not "{+time}", because that would be a floating-point value,
not an integer).
I was thinking: an epoch is just a time, and "int time" is a duration --
the number of seconds since the current epoch. So, the following should
work:
for 1 .. 2 -> {
use epoch time();
sleep 6;
say int time;
}
This should print something close to "6", twice.
But something niggled me: does the value of the RHS of a "use" get
evaluated at run time, or compile time? In perl5, that could definitely
would only execute the C once.
I could see 3 possible behaviors:
1. C sets the epoch for each iteration of the loop, thus calling
time() one per iteration
2. C executes just once, at compile time. Thus seconds iteration
prints approximately "12"
3. C does a compile-time binding of the epoch to the time()
function. So each iteration prints "0".
Which actually happens?
Re: Time::Local
Darren Duncan wrote: The object should not store anything other than this single numerical value internally (smart caching of conversions aside). I think we can all either agree with that, or dont-care it. The internal implementation is an implementation issue (or library). It doesn't need to be defined by the language. The one important thing is that that language shouldn't define semantics that require more than this single value (e.g. we shouldn't associate the epoch with the object).
Re: Time::Local
All, In the spirit of forward thinking and adaptability (and internationalization), I believe a core Time/Date object should be calendar agnostic and simply store some value that is easily convertable to any date + time on any calendaring system. I say forward thinking because this system will be forwards compatible with calendaring systems that don't yet exist, and backwards compatible with older calendars we haven't bothered to account for yet. I believe that at its core said object should simply store a count of rigorously defined time units relative to a rigorously defined epoch. What the epoch is and what the time unit is will need to be officially defined (eg, Jan 1, 2000; counting in fractions of seconds). The object should not store anything other than this single numerical value internally (smart caching of conversions aside). Save all human-desired representations to something that is computed on request, such as using a getter method named after the desired format; and setting would do the reverse. This can work with values in any calendaring system. With this system, date calculations and storage are trivially easy, and Perl's built-in date/time function would simply return that number or said object. All the complexity is in the getter/setter methods that are specific to what details a user wants, such as the day of week or an ISO formatted string. In fact, all of that actual conversion stuff would be what modules are good for. Perl internally just has to know about the one number. -- Darren Duncan
Re: Time::Local
Douglas P. McNutt wrote:
At 10:55 -0700 7/5/05, Dave Whipp wrote:
I don't understand why time() should return a numeric value at all.
Some of us like to use epoch time, as an integer, to create unique file names which sort
"right" in a shell or GUI.
You can use "{time - $epoch}" or "{time.as<%d>}" or "{int time}". (That
last one is not "{+time}", because that would be a floating-point value,
not an integer).
Re: Time::Local
At 10:55 -0700 7/5/05, Dave Whipp wrote: >I don't understand why time() should return a numeric value at all. Some of us like to use epoch time, as an integer, to create unique file names which sort "right" in a shell or GUI. -- --> From the U S of A, the only socialist country that refuses to admit it. <--
Re: Time::Local
Hi,
Juerd wrote:
> Ingo Blechschmidt skribis 2005-07-05 20:08 (+0200):
>> FWIW, I agree, but I'd like to propose standard overloadings:
>> say ~$time; # "Di 05 Jul 2005 20:01:42 CEST"
>
> Or perhaps not. In fact, rather not. Please let stringification be the
> ISO standard, and otherwise certainly sortable: year first, then
> month, then mday.
>
> 2005-07-05T20:01:42+0200
WRT to sorting: The Date/Time/whatever class should overload
&infix:«<=>», so sorting really works -- if you sort those ISO strings,
you'll probably get wrong results, as the timezone diff isn't taken
into account.
I don't have a strong opinion on the default format of the
stringification.
Could/should we use .as for this, to leave the choice to the programmer?
say time.as("%H:%M:%S"); # 20:26:36
Note though that it's inconsistent:
say "hi".as("%H:%M:%S"); # error
say time.as("%H:%M:%S"); # works
--Ingo
--
Linux, the choice of a GNU | "The future is here. It's just not widely
generation on a dual AMD | distributed yet." -- William Gibson
Athlon!|
Re: Time::Local
Dave Rolsky skribis 2005-07-05 11:41 (-0500): > >* .month and .wday are one-based. Sunday == 1. Haskell has them as > > enums which avoids off-by one confusion completely; I made them like > > I did because that's like humans think of them. > And yes again! No. Humans don't USE numbers for week days! So beginning at 1 makes no sense, except for humans who like creating lists like (undef, ). In fact, I would prefer to not having any 0 :) Now, for months, yes it does make lots of sense. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Time::Local
Ingo Blechschmidt skribis 2005-07-05 20:08 (+0200): > FWIW, I agree, but I'd like to propose standard overloadings: > say ~$time; # "Di 05 Jul 2005 20:01:42 CEST" Or perhaps not. In fact, rather not. Please let stringification be the ISO standard, and otherwise certainly sortable: year first, then month, then mday. 2005-07-05T20:01:42+0200 Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Time::Local
Hi, Dave Whipp wrote: > Larry Wall wrote: >> The time function always returns the time in floating point. > > I don't understand why time() should return a numeric value at all. > Surely it should return a DateTime (or Time) object. Using epochs in a > high level language seems like a really bad thing to be doing. If I > want "duration since epoch" then I should subtract the epoch from the > time -- resulting in a duration (which may indeed be a floating point > value). FWIW, I agree, but I'd like to propose standard overloadings: my $time = time;# some kind of Date/Time object say ~$time; # "Di 05 Jul 2005 20:01:42 CEST" say +$time; # seconds since the Perl 6 epoch # (2000-01-01 according to [1]) > For the sleep function, it seems reasonable to accept either a > DateTime or a Duration, or a number of seconds, > which would sleep either until the requested time, or for the > requested duration. --Ingo [1] http://groups.google.de/group/perl.perl6.internals/msg/a572113dc089481b -- Linux, the choice of a GNU | Elliptic paraboloids for sale. generation on a dual AMD | Athlon!|
Re: Time::Local
Larry Wall wrote: The time function always returns the time in floating point. I don't understand why time() should return a numeric value at all. Surely it should return a DateTime (or Time) object. Using epochs in a high level language seems like a really bad thing to be doing. If I want "duration since epoch" then I should subtract the epoch from the time -- resulting in a duration (which may indeed be a floating point value). my DateTime $epoch is constant = DateTime "2000-01-01 00:00:00"; my Num $seconds_since_epoch = time - $epoch; > In fact, > all numeric times are Num in Perl 6. Then you don't have to worry > about whether picosecond resolution is good enough. Time and > duration objects can, of course, do whatever they like internally, > and among themselves, but someone who says sleep($PI) should get a > $PI second sleep. For the sleep function, it seems reasonable to accept either a DateTime or a Duration, which would sleep either until the requested time, or for the requested duration. Sorry about the rant, but you seem to have pushed one of my hot buttons... Ditto Larry
Re: Time::Local
On Tue, 5 Jul 2005, Gaal Yahas wrote: Regarding Time::Local fields, it's an object now, so the order of things Should that be Time::localtime? In P5 there are Time::localtime & Time::gmtime, which are thin OO facades over the language builtins. Then there's the module Time::Local, which is entirely different. All of those provide useful functionality, and probably Time::Local should be part of the language, _or_ localtime & gmtime should be in a library. * .year is the Gregorian year, no 1900 offeset or anything like that. Yes! * .month and .wday are one-based. Sunday == 1. Haskell has them as enums which avoids off-by one confusion completely; I made them like I did because that's like humans think of them. And yes again! * .picoseconds - we don't promise this granularity is available by the system, but I don't suppose we'll ever need anything finer than that :-) The more granularity the better, really. DateTime right now supports nanoseconds, which was a semi-arbitrary choice that seemed granular enough. Picoseconds is even better. Anyone who needs more probably has some sort of special hardware providing their data anyway, and will need a special interface to it (hand waving). * Once we sort out context and want in pugs, I can return a List when one is expected, instead of an object. Then the order of fields becomes important and I'm inclined to go with year first, like the Haskell module, so that least significant things come last. This is the reverse of p5 Time::Local. When timelocal and timegm are implemented, they will of course use whatever order their inverses use. I'd agree that this makes the most sense. -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/
Re: Time::Local
On Tue, Jul 05, 2005 at 11:41:23AM -0500, Dave Rolsky wrote: > >Regarding Time::Local fields, it's an object now, so the order of things > > Should that be Time::localtime? In P5 there are Time::localtime & > Time::gmtime, which are thin OO facades over the language builtins. Then > there's the module Time::Local, which is entirely different. Hmm, I agree. I used Time::Local because that's what the draft Synopsis put them in, but Time is a better fit. > All of those provide useful functionality, and probably Time::Local should > be part of the language, _or_ localtime & gmtime should be in a library. Not my call, but I think we can add timelocal and timegm soon. They're mostly cleverly-caching facades to Time.new anyway, no? Drop by on #perl6 if you want to hack on the Prelude side of this. -- Gaal Yahas <[EMAIL PROTECTED]> http://gaal.livejournal.com/
Re: Time::Local
On Tue, Jul 05, 2005 at 08:16:54AM -0700, Larry Wall wrote:
> I don't think either of those are good human engineering. I would
> like the preferred Perl 6 form to simply be:
>
> multi sub localtime(Num $?when = time) returns Time::Local { ... }
Done.
I take it that the rest is okay? If so I'll submit a doc patch to S29.
--
Gaal Yahas <[EMAIL PROTECTED]>
http://gaal.livejournal.com/
Re: Time::Local
On Tue, Jul 05, 2005 at 04:39:48PM +0300, Gaal Yahas wrote:
: As for the function signatures:
:
:multi sub localtime(Rat $?when = time) returns Time::Local { ... }
:multi sub localtime(Int $sec, Int ?$pico = 0) returns Time::Local {...}
:
: The first form uses the second, but might be less precise.
I don't think either of those are good human engineering. I would
like the preferred Perl 6 form to simply be:
multi sub localtime(Num $?when = time) returns Time::Local { ... }
The time function always returns the time in floating point. In fact,
all numeric times are Num in Perl 6. Then you don't have to worry
about whether picosecond resolution is good enough. Time and
duration objects can, of course, do whatever they like internally,
and among themselves, but someone who says sleep($PI) should get a
$PI second sleep. Our computers are capable of floating point these
days, and I consider any other numeric time format to be cultural
baggage. I particularly loathe any kind of two integer format.
Sorry about the rant, but you seem to have pushed one of my hot buttons...
Larry
Time::Local
I've added localtime to pugs (r5233, 5236), to address Dave Rolsky's needs
for DateTime; but I'm noticing S29 doesn't spec this and nearby builtins
yet. I'd like to raise the questions I encountered / stipulations I've
made. Please let me know if I'm in error or update S29 if I am not.
Regarding Time::Local fields, it's an object now, so the order of things
matters less now than it did in p5. The fields I've made available
naturally follow GHC's CalendarTime type[1]. The important deviations
from p5 are:
* .year is the Gregorian year, no 1900 offeset or anything like that.
(Haskell doesn't promise accuracy in the readable version of
pre-Gregorian dates, which I think is okay for us as well, as long
as the opaque internal representation remains consistent. That's part
of where libraries such as DateTime can help.)
* .month and .wday are one-based. Sunday == 1. Haskell has them as
enums which avoids off-by one confusion completely; I made them like
I did because that's like humans think of them.
* .picoseconds - we don't promise this granularity is available by the
system, but I don't suppose we'll ever need anything finer than that
:-)
* Once we sort out context and want in pugs, I can return a List when
one is expected, instead of an object. Then the order of fields
becomes important and I'm inclined to go with year first, like the
Haskell module, so that least significant things come last. This is the
reverse of p5 Time::Local. When timelocal and timegm are implemented,
they will of course use whatever order their inverses use.
As for the function signatures:
multi sub localtime(Rat $?when = time) returns Time::Local { ... }
multi sub localtime(Int $sec, Int ?$pico = 0) returns Time::Local {...}
The first form uses the second, but might be less precise.
[1]
http://haskell.org/ghc/docs/latest/html/libraries/base/System.Time.html#t%3ACalendarTime
--
Gaal Yahas <[EMAIL PROTECTED]>
http://gaal.livejournal.com/
