Re: [Scheme-reports] current-posix-second is a disastrous mistake

[Alaric Snell-Pym <alaric@x>]

On 12/15/10 11:09, Vitaly Magerya wrote:

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

Agreed

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

Was it? I thought he was just arguing that TAI (which goes up linearly)
was better than POSIX seconds (which go up nonlinearly due to leap
seconds), rather than an argument about whether we should present
absolute or relative time.

Personally, on the latter point, I'd be inclined to standardise relative
time as the most basic standard, as tiny systems can at least start a
reasonably accurate second counter at startup, even if they lack
absolute clocks. A separate procedure that returns the offset between
relative time and some epoch, or #f if this is not known, would be the
next level, offering an absolute time reference...

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

That'd be fine by me! A procedure that returns the number of seconds
between two arbitrary dates (along with a certainty, so that dates
extending beyond the current leap-second table, or back beyond UTC
began, can give approximate answers) would round it out nicely.

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

Yeah, I know, but such environments just can't have accurate UTC <->
actual time conversions, full stop. So they'll have to have
approximations (and, ideally, be informed of this fact using a certainty
flag, etc).

ABS

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

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