Re: [Scheme-reports] current-posix-second is a disastrous mistake
Vitaly Magerya 15 Dec 2010 11:09 UTC
On 2010-12-15 12:22, Alaric Snell-Pym wrote:
>> You can't use TAI to represent dates in the future,
>> as it would require leap seconds tables that are only published six
>> months before the leap seconds occur.
>
> But we're not trying to represent dates; we're trying to represent the
> pssage of time.
Any monotonic clock with unspecified origin is sufficient to represent
passage of time. What Alex suggested was to use TAI clock specifically
to represent both passage of time and UTC (civil time, wall clock time,
"date", call it as you wish).
My point is that TAI can not be reliably used to represent UTC (or POSIX
time, which is a variation thereof), and vice versa. Also, since you
don't care about your clock's point of origin when measuring physical
time intervals, TAI is an overkill here as well.
> We'd use a date object (which refers to a particular
> calendar) to represent dates.
That seems like the only reasonable choice: have a complex "date" object
for UTC, and a simple monotonically increasing number for physical time
(and drop the assumption that you can freely convert between the two).
> Then perhaps Scheme distributions will come with a leap-second file, and
> encourage its periodic updating. That shouldn't be too burdensome...
"Periodic" means every 6 month, and there are lots of places where this
is burdensome (which is why we have things like IE6 and Debian Stable).
_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports