Re: Temporal seems a bit wibbly-wobbly
On Feb 24, 6:05 am, markjr...@gmail.com (Mark J. Reed) wrote: Fair enough: official TAI is only known exactly after the fact. Does official TAI means what BIPM says it means, and just plain TAI means whatever perl6 wants it to mean? TAI is an achievement for technical merits, but even moreso for diplomatic merits. It is the time to which any who choose are allowed to contribute in order that it be international. As such its characteristics are unsuitable for the purposes of operational systems, thus the distinct but TAI-like GPS time, Galileo System Time, BeiDou System Time. Will TAI as used by perl6 be as technically well-defined and diplomatically astute as official TAI? Comparing this to the POSIX situation is a rather harsh overstatement, I feel. I suspect that for the BIPM being off by 10 ns is more annoying than POSIX being off by 1 s. I urge that perl6 only use unadorned TAI for purposes approved by the folks at BIPM. the only mention of TAI is in reference to its initialization point of 1958-01-01T00:00:00 (or MJD 36204.0, if you prefer) as one of the predefined epochs. As a practical matter the era of atomic time as civil time began 1972-01-01. Prior to then there were only a handful of folks outside of national metrology institutes who had access to TAI. What does TAI mean in perl6 before that date?
Re: Temporal seems a bit wibbly-wobbly
On Tue, Feb 23, 2010 at 10:02:02AM +0300, Richard Hainsworth wrote: - Time Zone, which can differ from GMT by halves of an hour. quarter hours in at least one place (Nepal) This doesn't affect your reasoning. Also, time zone abbreviations are ambiguous. PST can be Pacific Standard Time, Pakistan Standard Time, Phillippine Standard Time. Probably others are similarly overloaded. This means that even a well formed time string complete with timezone abbreviation isn't actually absolute. - The legal jurisdiction. And oh gosh is *that* one fun. eg do we or don't we have daylight saving time? Nicholas Clark
Re: Temporal seems a bit wibbly-wobbly
On Mon, Feb 22, 2010 at 6:50 PM, Daniel Ruoso dan...@ruoso.com wrote: So why have the duration TAI-based? Simply because TAI is supposedly immutable as a scale, so it's predictable. Gregorian time is not immutable and timezone definitions are not anyhow predictable. OK, this seems to be a point of confusion. TAI *is defined in terms of the Gregorian calendar*.It is not just a sequence of anonymous seconds ticking off at the rate specified by SI. TAI specifies a name for each second, not just the amount of time between them. And that name is a date/time using the Gregorian calendar. If you like, you can convert it to a Julian Date, but that's a one-to-one mapping. You're still going to get a value that's wrong for civil purposes - that is, currently 34 seconds fast compared to an NTP-synchronized clock. If Perl's internal idea of time is just a count of atomic seconds, great. That, however, is not TAI. UTC and TAI and the proposed leap-second-free UTC-replacement TI all tick at the same rate and at the same time, and you can devise any number of time scales that do likewise, differing only in the labels. -- Mark J. Reed markjr...@gmail.com
Re: Temporal seems a bit wibbly-wobbly
On Tue, 23 Feb 2010, Nicholas Clark wrote: On Tue, Feb 23, 2010 at 10:02:02AM +0300, Richard Hainsworth wrote: - Time Zone, which can differ from GMT by halves of an hour. quarter hours in at least one place (Nepal) This doesn't affect your reasoning. Also, time zone abbreviations are ambiguous. PST can be Pacific Standard Time, Pakistan Standard Time, Phillippine Standard Time. Probably others are similarly overloaded. EST = Eastern Standard time, ie. +1000 from GMT. Has anyone noticed that I'm referring to Australia? Both Aust. USA have Eastern Standard Time, but they're quite different times :). This means that even a well formed time string complete with timezone abbreviation isn't actually absolute. That's why we use +1000 now :). - The legal jurisdiction. And oh gosh is *that* one fun. eg do we or don't we have daylight saving time? ...and are we starting 3 months early this year to accomodate the Olympics? :) - | Name: Tim Nelson | Because the Creator is,| | E-mail: wayl...@wayland.id.au| I am | - BEGIN GEEK CODE BLOCK Version 3.12 GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- PE(+) Y+++ PGP-+++ R(+) !tv b++ DI D G+ e++ h! y- -END GEEK CODE BLOCK-
Re: Temporal seems a bit wibbly-wobbly
Em Dom, 2010-02-21 às 21:09 -0800, Larry Wall escreveu: I now see that the most important determinant of DateTimes is neither the Dates nor the Times themselves, but which TZ you're in. I propose renaming Temporal to TZ, so we get TZ::Date, TZ::Time, etc, since they're all dependent primarily on exactly where on earth you are, which determines how civil (or incivil) your cultural time is. It will also tend to prevent people from assuming anything universal about such types. This issue was addressed when we got into the difference between Instant and DateTime. The thing is, much like a Str can't be seen as a Buf without an encoding... a Instant can't be seen as a Date without a timezone... That's the barrier between Instant and DateTime, as currently stated at S32/Temporal.pod... Take a look at all the classes and roles declared there... daniel
Re: Temporal seems a bit wibbly-wobbly
Em Dom, 2010-02-21 às 21:28 -0800, Larry Wall escreveu: On Sat, Feb 20, 2010 at 10:39:20AM -0500, Mark J. Reed wrote: : I just want to know what Perl 6 time zero is. Well, there's no such thing as time 0 in Perl 6, in the sense that Instant is more-or-less opaque. I'd just like to add that Instant is not more-or-less opaque. It is entirely opaque. That basically means it probably is architecture and implementation dependant. The point is... asking for the amount of seconds since 01/01/1970 requires you to convert that date, in a particular timezone in a particular calendar (gregorian) to an instant, then ask for the amount of seconds elapsed from that instant to the current instant (and that will return you a Duration object (which conceptually only know about TAI), which in turn can be converted (provided a timezone and a calendar) to a Gregorian::Duration. daniel
Re: Temporal seems a bit wibbly-wobbly
On Mon, Feb 22, 2010 at 1:13 PM, Daniel Ruoso dan...@ruoso.com wrote: Em Dom, 2010-02-21 às 21:28 -0800, Larry Wall escreveu: On Sat, Feb 20, 2010 at 10:39:20AM -0500, Mark J. Reed wrote: : I just want to know what Perl 6 time zero is. Well, there's no such thing as time 0 in Perl 6, in the sense that Instant is more-or-less opaque. I'd just like to add that Instant is not more-or-less opaque. It is entirely opaque. Not according to S0, which says that an Instant will numify to the number of TAI seconds since the TAI epoch. That's not opaque. And since it apparently wasn't clear, all I'm asking for is what the TAI epoch is. Again, I *assume* it's January 1, 1958 at midnight UT2, at which point TAI was synchronized to have exactly that same value, but it's not stated as such in the spec, and there are other reasonable values (onset of UTC in 1972; switch to modern relativistic corrections to the measured SI seconds in 1977). The point is... asking for the amount of seconds since 01/01/1970 requires you to convert that date, in a particular timezone in a particular calendar (gregorian) to an instant, then ask for the amount of seconds elapsed from that instant to the current instant (and that will return you a Duration object (which conceptually only know about TAI), which in turn can be converted (provided a timezone and a calendar) to a Gregorian::Duration. Two different problems. The TAI epoch is defined as a point on the TAI scale, and the number of TAI seconds since that point is always well-defined. When asking for epoch-based time, you're not starting with a Gregorian DateTime and trying to convert it. But even if you did do such a conversion, as long as you assume that the input date is UTC, the conversion to TAI is well-defined, too. (And if you don't make that assumption, then you're opening a large can of worms; see e.g.http://www.ucolick.org/~sla/leapsecs/epochtime.html ). The problem really comes in with the fact that POSIX systems ignore leap seconds, and literally cannot distinguish them in any way from their adjacent non-leap neighbor. So you wind up with the fact that an arbitrary set of 24 (so far) POSIX time_t integer values actually cover a 2-second span of time instead of a 1-second span, with no way to identify which values those are without a lookup table, and no way to predict ahead of time which future values will be likewise stretched. -- Mark J. Reed markjr...@gmail.com
Re: Temporal seems a bit wibbly-wobbly
On Mon, Feb 22, 2010 at 1:31 PM, Mark J. Reed markjr...@gmail.com wrote: Not according to S0, which says that an Instant will numify to the ^ S02. number of TAI seconds since the TAI epoch. That's not opaque. -- Mark J. Reed markjr...@gmail.com
Re: Temporal seems a bit wibbly-wobbly
On Mon, Feb 22, 2010 at 4:38 PM, Daniel Ruoso dan...@ruoso.com wrote: The biggest difference proposed by the use of TAI is that when you ask for the number of seconds between 2008-12-31T23:59:59+ and 2009-01-01T00:00:00+ you'll get 2 because of the leap second. But you don't need to know how many seconds there were in the TAI scale since the 1958 epoch to find that out, you just need to know when we had leap seconds. What do you mean? The number of seconds between 2008-12-31T23:59:59+ TAI and 2009-01-01T00:00:00+ TAI was 1 because TAI doesn't have leap seconds. UTC does, but TAI doesn't.
Re: Temporal seems a bit wibbly-wobbly
On Mon, Feb 22, 2010 at 4:38 PM, Daniel Ruoso dan...@ruoso.com wrote: And my point is precisely that the spec doesn't define it because it is implementation and architecture dependant. And what's the point of making it so? If you require arithmetic results in TAI seconds, I don't see the benefit of not specifying the epoch, since conversion to and from the epoch would be a simple addition or subtraction - much less expensive than converting from the internal TAI representation to civil time or back. The point is that you shouldn't use a number alone to represent an instant But why not? An instant is just a point on the number line (of the coordinate time in question, which we've established as TAI). A number is an eminently reasonable representation of a point in one-dimensional space. But only if you have a well-defined origin. Note that not even the TAI coordination happens in terms of number of seconds since X, but rather happens in terms of Gregorian or Julian dates. Exactly. See below. The biggest difference proposed by the use of TAI is that when you ask for the number of seconds between 2008-12-31T23:59:59+ and 2009-01-01T00:00:00+ you'll get 2 because of the leap second. But that's not true unless those two strings are given in UTC. In TAI, 2008-12-31T23:59:59Z was followed by 2009-01-01T00:00:00Z only one second later. That's because, as you say, TAI is not just a count of seconds - it is a fully-specified date/time value, with year, month, day, hour, minute, and second - and it doesn't match civil clocks. If the interface between Perl time and human time is going to be done through UTC, then I don't see the point in specifying that it's TAI behind the scenes. Especially if you're not specifying the epoch. The number of seconds between two points in time in UTC is exactly the same as the number of seconds between two points in time in TAI, by definition. Only the labels differ. And if, as you imply above, the labels will be UTC - which they pretty much have to be since that's what humans use - then Perl6 is using UTC, not TAI. It's just using *real* UTC, not POSIX's broken idea of it that claims 24 seconds out of the past 40 years never happened. -- Mark J. Reed markjr...@gmail.com
Re: Temporal seems a bit wibbly-wobbly
On Mon, Feb 22, 2010 at 4:49 PM, Buddha Buck blaisepas...@gmail.com wrote: On Mon, Feb 22, 2010 at 4:38 PM, Daniel Ruoso dan...@ruoso.com wrote: The biggest difference proposed by the use of TAI is that when you ask for the number of seconds between 2008-12-31T23:59:59+ and 2009-01-01T00:00:00+ you'll get 2 because of the leap second. But you don't need to know how many seconds there were in the TAI scale since the 1958 epoch to find that out, you just need to know when we had leap seconds. What do you mean? The number of seconds between 2008-12-31T23:59:59+ TAI and 2009-01-01T00:00:00+ TAI was 1 because TAI doesn't have leap seconds. UTC does, but TAI doesn't. Exactly. If Perl6 is thoroughly TAI, then any time you ask it what time it is you'll get an answer that's 34 or more seconds fast compared to the clock on the wall. In exchange for this, you know that you can take the number of minutes, hours, or days between two times and multiply by a constant to get an accurate count of seconds between them. If, instead, Perl6 uses UTC, then its time labels will agree with our clocks. But that means that some minutes, hours, and days will be a second longer than the rest, so you can no longer do a simple multiplication to convert to seconds. (Unless you're looking for a POSIX time stamp instead of the actual length of the interval.) I submit that if the inputs and outputs of Temporal are UTC, then Perl is using UTC, not TAI. Is it TAI internally? Well if it's manipulating years, months, days, hours, and minutes as their TAI values, then yes, but if it's just working with an absolute count of atomic seconds, then there's no reason to say that it's TAI vs. UTC, because at that level, they completely agree with each other. -- Mark J. Reed markjr...@gmail.com
Re: Temporal seems a bit wibbly-wobbly
2010/2/22 Mark J. Reed markjr...@gmail.com If the interface between Perl time and human time is going to be done through UTC, then I don't see the point in specifying that it's TAI behind the scenes. Especially if you're not specifying the epoch. The number of seconds between two points in time in UTC is exactly the same as the number of seconds between two points in time in TAI, by definition. Only the labels differ. And if, as you imply above, the labels will be UTC - which they pretty much have to be since that's what humans use - then Perl6 is using UTC, not TAI. It's just using *real* UTC, not POSIX's broken idea of it that claims 24 seconds out of the past 40 years never happened. Okay, most replies are in the same tone, so I'll reply just here... The problem is with the idea that TAI or UTC are the interface between Perl time and Human Time, because that implies we could neglect the semantics of the input type and store everything in a number of TAI seconds since the epoch (after converting from the localtime to UTC) and store it like that. DatesTimes are just not that simple, if I say 2009-01-01T00:00:00-0300 it can't simply be converted to UTC then to TAI and be stored like that. because that would mean a different year, and that semantic is not neglectable. That is why the Instant is not just a number, but a full specification of a given instant. Which might say 2009-01-01T00:00:00 BRT which happens to be GMT-3 but a few years ago had DST (it's in the south emisphere, so summer time), but it doesn't have it nowadays. More importantly, an Instant is not a Duration since some epoch. Instant and Duration are completely different beasts, for instance... a Gregorian duration of 1 day is not the same as 86400 seconds, simply because we have days with 23 hours and days with 25 hours. and adding a day should ignore the number of seconds in that day. As well as adding a month should ignore the numbers of days in the month and so on... So, there isn't one interface between Perl time and Human time, simply because there isn't just one Human time, so we deal with all human times... Note that the same way we have Gregorian::DateTime and Gregorian::Duration, we can have TAI::DateTime and TAI::Duration, Instant and Duration are just the most abstract roles for that types (also note that TAI doesn't have timezones, it started aligned with UTC and drifted away ever since). So why have the duration TAI-based? Simply because TAI is supposedly immutable as a scale, so it's predictable. Gregorian time is not immutable and timezone definitions are not anyhow predictable. So when you get a duration (in the precision of seconds) it specifies an immutable amount of time. But if it's not in the precision of seconds, then well... it can be anything... daniel
Re: Temporal seems a bit wibbly-wobbly
On Feb 22, 2:23 pm, markjr...@gmail.com (Mark J. Reed) wrote: I submit that if the inputs and outputs of Temporal are UTC, then Perl is using UTC, not TAI. Is it TAI internally? Only the time scale which is approved by the ITU-R for use in radio broadcasts has any international backing. Because it is the internationally-approved and broadcast time scale there are many systems which rely on its value, and for that reason it is the only practical choice for many applications and specifications. At present that time scale is called UTC, and at present it has leap seconds. If those are not suitable for an application then there is little option but to create one's own time scale with the necessary characteristics. POSIX has created its own time scale, but confusion and problems result from calling it UTC. It is probably worth pointing out that TAI is maintained only by the BIPM, and if asked the BIPM will almost certainly respond that it is not appropriate to use TAI for any standard purposes. Past objections from various folks have included metrological jargon such as TAI is not realized or not available; that only UTC is realized. The same folks have objected to the use of GPS time because it is a US Department of Defense time scale with no international authority behind it.
Re: Temporal seems a bit wibbly-wobbly
To add to Daniel's comment. Lets recast the time/date discussion in another way. The way times and dates are quoted (human time) depends on: - religion denomination: the Jewish, Muslim, and Bahai religions have their own calendars as part of their religions; Orthodox and Catholic (including Protestant) denominations have different calandars. - Time Zone, which can differ from GMT by halves of an hour. - The legal jurisdiction. - Zero instant. Specifying any mechanism for providing a 'human' time requires a decision about all of the above. Perl6 is agnostic and so does not specify anything that requires a religious or location bias. Clearly, such decisions are necessary, but these will be made by the implementor, rather than being set in stone in the specification. Clever implementors will provide mechanisms to adapt the Time/Calendar decisions to suit the individual programer. In all situations, how time is counted is crucial and the current reasonable standard is TAI. Hence this is in the Perl6 specification. In terms of usage, most people, if you think about it, are actually more interested in durations, what happens between a finite start and a finite end, than we are in some form of eternity, viz, time from a distant beginning to the present. Regards, Richard Daniel Ruoso wrote: 2010/2/22 Mark J. Reed markjr...@gmail.com If the interface between Perl time and human time is going to be done through UTC, then I don't see the point in specifying that it's TAI behind the scenes. Especially if you're not specifying the epoch. The number of seconds between two points in time in UTC is exactly the same as the number of seconds between two points in time in TAI, by definition. Only the labels differ. And if, as you imply above, the labels will be UTC - which they pretty much have to be since that's what humans use - then Perl6 is using UTC, not TAI. It's just using *real* UTC, not POSIX's broken idea of it that claims 24 seconds out of the past 40 years never happened. Okay, most replies are in the same tone, so I'll reply just here... The problem is with the idea that TAI or UTC are the interface between Perl time and Human Time, because that implies we could neglect the semantics of the input type and store everything in a number of TAI seconds since the epoch (after converting from the localtime to UTC) and store it like that. DatesTimes are just not that simple, if I say 2009-01-01T00:00:00-0300 it can't simply be converted to UTC then to TAI and be stored like that. because that would mean a different year, and that semantic is not neglectable. That is why the Instant is not just a number, but a full specification of a given instant. Which might say 2009-01-01T00:00:00 BRT which happens to be GMT-3 but a few years ago had DST (it's in the south emisphere, so summer time), but it doesn't have it nowadays. More importantly, an Instant is not a Duration since some epoch. Instant and Duration are completely different beasts, for instance... a Gregorian duration of 1 day is not the same as 86400 seconds, simply because we have days with 23 hours and days with 25 hours. and adding a day should ignore the number of seconds in that day. As well as adding a month should ignore the numbers of days in the month and so on... So, there isn't one interface between Perl time and Human time, simply because there isn't just one Human time, so we deal with all human times... Note that the same way we have Gregorian::DateTime and Gregorian::Duration, we can have TAI::DateTime and TAI::Duration, Instant and Duration are just the most abstract roles for that types (also note that TAI doesn't have timezones, it started aligned with UTC and drifted away ever since). So why have the duration TAI-based? Simply because TAI is supposedly immutable as a scale, so it's predictable. Gregorian time is not immutable and timezone definitions are not anyhow predictable. So when you get a duration (in the precision of seconds) it specifies an immutable amount of time. But if it's not in the precision of seconds, then well... it can be anything... daniel
Re: Temporal seems a bit wibbly-wobbly
On Feb 19, 10:30 pm, la...@wall.org (Larry Wall) wrote: 2000 would have been a lovely epoch if only the astronomers had kept their grubby hands off of civil time. The astronomers might love to have the power to control something like that, but I'm afraid that none who are alive now can take credit for the international political situation. The root of the problem is demonstrated here http://www.ucolick.org/~sla/leapsecs/epochtime.html Until the governments of the world agree on a major change in the status quo there will be leap seconds.
Re: Temporal seems a bit wibbly-wobbly
On Sat, Feb 20, 2010 at 06:20:22PM -0800, Steve Allen wrote: : On Feb 19, 10:30 pm, la...@wall.org (Larry Wall) wrote: : 2000 would have been a lovely epoch if only the astronomers had kept : their grubby hands off of civil time. : : The astronomers might love to have the power to control something like : that, but I'm afraid that none who are alive now can take credit for : the international political situation. The root of the problem is : demonstrated here : http://www.ucolick.org/~sla/leapsecs/epochtime.html : Until the governments of the world agree on a major change in the : status quo there will be leap seconds. I apologize to all the living astronomers for maligning them. :) I now see that the most important determinant of DateTimes is neither the Dates nor the Times themselves, but which TZ you're in. I propose renaming Temporal to TZ, so we get TZ::Date, TZ::Time, etc, since they're all dependent primarily on exactly where on earth you are, which determines how civil (or incivil) your cultural time is. It will also tend to prevent people from assuming anything universal about such types. Larry
Re: Temporal seems a bit wibbly-wobbly
On Sat, Feb 20, 2010 at 10:39:20AM -0500, Mark J. Reed wrote: : I just want to know what Perl 6 time zero is. Well, there's no such thing as time 0 in Perl 6, in the sense that Instant is more-or-less opaque. But it's currently specced to the TAI epoch, if you force it. I could be argued into 2000, if people can actually agree on how far that is from the TAI epoch. But the internals of Instant are likely to be something like the current year plus an offset from that in any case, so it doesn't really much matter from the standpoint of efficiency which epoch we pick. That says to me that if it's numerically the TAI epoch, it doesn't really matter much that it's a very large number, and using such a large number will tend to discourage people from using it as a number. :) That being said, we could easily have a user-visible constant array with values like %Epoch[2000] and such, and then you can just pick your epoch (if it's on a GMT year boundary). So the first thing a program might do is: my Instant $unix-epoch = %Epoch[1970]; Or maybe it should be a method on Instant: my Instant $unix-epoch .= epoch(1970); Course, that still doesn't solve the problem that POSIX file mod times are ignorant of leap seconds, so subtracting $unix-epoch from it will still have the UTC vs TAI mismatch. I can forgive dead astronomers, but parts of POSIX just oughta die. Some days it seems like standards committees are even worse than governments for standing in the way of progress... Larry
Re: Temporal seems a bit wibbly-wobbly
I don't see the need for keeping UTC within a second of UT, either. I also think the Gregorian correction is a little silly, but at least it only rears its head 3 times in 400 years. Still, that horse has sailed, right? Perl 6 is using TAI, and the burden of correcting for civil time is on the implementation. I wasn't trying to re-raise the spectre of leap seconds. I just want to know what Perl 6 time zero is. On Saturday, February 20, 2010, Brandon S. Allbery KF8NH allb...@ece.cmu.edu wrote: (re subject: does it go `Ding!' when there's Stuff?) On Feb 20, 2010, at 00:30 , Larry Wall wrote: but an astronomer? But no, many millions of computers have to accommodate to the convenience of a very few people. And most computers still don't know how to do even that accommodation, since POSIX time is blissfully unaware of leap seconds... Sorry, you pushed one of my hot buttons. Grrr! :) Not just yours; quite a few of us wish NTP would return to the demesne of mad scientists and astronomers, to be replaced by a saner (i.e. non-leap-second) version of SNTP. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -- Mark J. Reed markjr...@gmail.com
Temporal seems a bit wibbly-wobbly
S02 says that if pressed, an Instant will numify into a count of atomic seconds since the TAI epoch - but what is the TAI epoch? TAI is normally expressed in the same terms as civil time - year, month, date, hour, minute, second, fraction of second, according to the Gregorian calendar, or else as a Julian Day number. As such, it doesn't really have an epoch built into the concept. (And S32 refers to TAI *as* an epoch, which is inaccurate. An epoch is a particular instant; TAI is a system of measuring time.) Using Instants as numbers is discouraged, but I still believe the epoch should be part of the spec. Once we're requiring atomic time, having the actual numeric value match is just a matter of adding a constant to whatever the natural choice might be on a given implementation. As far as I can see, there are a few reasonable values; roll out the bike shed! My first guess would be midnight on January 1st, 1958, which was when the international atomic time standard was initialized (and synchronized to universal time, specifically UT2), though it wasn't called TAI until 1971. 1 Jan 1977 was when TAI started ticking at the current speed (before that the atomic clock measurements were uncorrected for relativistic effects due to the altitude of the clocks above sea level). 1 Jan 2000 is a nice round number and corresponds to the current epoch used for astronomical calculations (though that's technically noon Terrestrial Time, which was 11:59:27.816 TAI, and I think an exact second in TAI makes more sense for an epoch.) Before that point there wasn't an atomic time standard, but of course you can continue to count atomic seconds backwards in time as far as you like. Since TAI moments are normally given using calendar dates, you could use the epoch of the calendar, though you'll get a few more digits in time values for the present. But what is the epoch of our calendar? January 1st of the year 1? Of the year 0 (a.k.a. 1 BC)? Perhaps November 30th, 1 BC (which is the normalized result of asking for day 0 of month 0 of year 0 when January is month 1)? And regardless of the above, is it that date in the Gregorian calendar we now use, or the Julian calendar which was in effect (at least in Rome) at the time? Or the incorrectly-implemented variation on the Julian calendar which was *really* in effect at that time? TAI moments are sometimes given as Julian Days, so it might make sense to use JD 0.0, though since that was noon UT on January 1st, 4713 BC in the Julian calendar (November 24, 4714 BC in the Gregorian), you'll even more digits. Alternatively you could use Modified Julian Day 0.0, which was midnight UT on November 17, 1858 (the epoch of VMS system time). I note that Rakudo currently uses the time_t value directly. I think 1 Jan 1970 is a poor choice of epoch for TAI time; having time values so close to but not the same as time_t values would create undue confusion. -- Mark J. Reed markjr...@gmail.com
Re: Temporal seems a bit wibbly-wobbly
2000 would have been a lovely epoch if only the astronomers had kept their grubby hands off of civil time. But no, we still have to put up with leap seconds in civil time, for no good reason that I can discern. We should adjust civil time once a century or so, I think. After all, civil time is off by *minutes* anywhere but the center of your timezone stripe. Why should a few seconds drift off of midnight matter to anyone but an astronomer? But no, many millions of computers have to accommodate to the convenience of a very few people. And most computers still don't know how to do even that accommodation, since POSIX time is blissfully unaware of leap seconds... Sorry, you pushed one of my hot buttons. Grrr! :) Larry
Re: Temporal seems a bit wibbly-wobbly
(re subject: does it go `Ding!' when there's Stuff?) On Feb 20, 2010, at 00:30 , Larry Wall wrote: but an astronomer? But no, many millions of computers have to accommodate to the convenience of a very few people. And most computers still don't know how to do even that accommodation, since POSIX time is blissfully unaware of leap seconds... Sorry, you pushed one of my hot buttons. Grrr! :) Not just yours; quite a few of us wish NTP would return to the demesne of mad scientists and astronomers, to be replaced by a saner (i.e. non- leap-second) version of SNTP. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon universityKF8NH PGP.sig Description: This is a digitally signed message part
