[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Scheme-reports] current-posix-second is a disastrous mistake
On Wed, Dec 15, 2010 at 10:27 AM, Vitaly Magerya <vmagerya@x> wrote:
> On Wed, 15 Dec 2010, Alex Shinn wrote:
>> > 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).
>> I said no such thing.
> True. You said that a good thing about providing TAI clock is that
> you can easily obtain current POSIX seconds from it. Correct? My
> argument is that you can't.
The intent was that `current-posix-seconds' can be easily
implemented in terms of `current-tai-seconds'. Other instances
of POSIX time such as found in timestamps and timers can
also be converted. If you want to work with calendar datetimes
then you shouldn't be converting them to seconds at all.
> TAI is of limited use here though. If you need to represent "now +
> N seconds", you use a monotonic clock with arbitrary point of origin.
> If you need to represent "2029-02-12 19:31:12.5 EET", you use a
> date object that contains all the fields separately.
Of course. That was the point of my example.
> > and presumably a record-like data type for dates.
> Now I'm confused. Will the date object internally store only TAI
Why are you trying so hard to put such strange words
into my mouth? What datetime class have you ever
seen which uses TAI seconds as one of the fields? A
datetime class has year, month, day, hour, minute, second,
etc. as you yourself said above.
I worked for 8 years on calendaring and event software,
and all of our datetimes were represented with a class
that stored all components separately, and was serialized
in ISO-8601 format (which does have limitations - we
used to joke about the Y10k problem). We never converted
these to either POSIX or TAI seconds.
Please understand, the context of the WG1 discussion is about
time, not dates. We want a way to obtain the current time
(and in WG1 are unlikely to provide anything beyond that).
The datetime API will be part of WG2, and can be implemented
in portable Scheme, assuming you have a way to compute the
Scheme-reports mailing list