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.


Daniel Ruoso wrote:
2010/2/22 Mark J. Reed <>

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

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...


Reply via email to