On 12/15/10 17:02, John Cowan wrote:

>> The date of my fortieth birthday is defined in the Gregorian calendar -
>> it's 2020-04-04. That date refers to a period of time that's about 24
>> hours long, but the mapping from that date to those two endpoint
>> TAI-seconds-since-epoch values is indeed as yet unknown.
>
> Your birthday is defined by local civil time, and there is no assurance
> that Parliament won't put the whole country on UTC+1 with summer time
> UTC+2 by then, or for that matter on UTC all the time, if the euroskeptics
> win.  *That* difference swamps any question of TAI-UTC issues.
>
> And of course if you moved to Western China, your birthday would be
> even more different.

Indeed! Calendars and timestamps are entirely different things, so
objecting to TAI-based timestamps as they don't have a decent mapping to
calendar time is ill-advised...

> The only safe way to refer to local civil times in the future is by
> reference to a broken-down time and a place.  Thus stock options are dated
> "2020-04-04 at 5 PM New York (or London) time."

Oooh, I'm getting stock options for my birthday? Thanks! ;-p

>> It will solve the problem of knowing how many seconds elapsed between
>> two points in time, which is useful for all sorts of embedded control
>> systems that need to measure or maintain rates of various things
>> happening, ensure that important tasks are performed at least or at most
>> once per second, and so on, that videos and sound are played back at the
>> correct speed, and so on!
>
> Arbitrary-epoch SI time accomplishes that, and better than TAI
> because its values can be fixnums.
>

Yep. Basing it on the TAI (or any other) epoch will just help to make
the time values have more "portable" significance, is all. Which must be
weighed against other considerations, such as convenient representation
of nearby times as small numbers.

ABS

--
Alaric Snell-Pym
http://www.snell-pym.org.uk/alaric/

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports