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>
