Alaric Snell-Pym scripsit:

> But we're not trying to represent dates; we're trying to represent the
> pssage of time. We'd use a date object (which refers to a particular
> calendar) to represent dates.

Even calendrical systems need a set of common reference points, so that
we can equate particular date-times in one calendar with those in another.
If you look at my TimeAdvancedCowan proposal (which was what I originally
posted about), you'll see what broken-out date(-time) objects look like.

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

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

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

--
Even the best of friends cannot                 John Cowan
attend each others' funeral.                    cowan@ccil.org
        --Kehlog Albran, The Profit             http://www.ccil.org/~cowan

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