[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Scheme-reports] current-posix-second is a disastrous mistake
- To: Taylor R Campbell <campbell+scheme@x>
- Subject: Re: [Scheme-reports] current-posix-second is a disastrous mistake
- From: Alex Shinn <alexshinn@x>
- Date: Mon, 13 Dec 2010 21:33:08 -0800
- Cc: scheme-reports@x
- In-reply-to: <E1PQtfd-0005Vf-LD@kusanagi.appsolutions.com>
- References: <E1PQtfd-0005Vf-LD@kusanagi.appsolutions.com>
On Thu, Dec 9, 2010 at 7:28 PM, Taylor R Campbell
<campbell+scheme@x> wrote:
> At <http://trac.sacrideo.us/wg/wiki/TimeCowan> is a proposal for a
> procedure called CURRENT-POSIX-SECOND that returns the number of
> seconds that have elapsed since 1970-01-01T00:00:00Z[*], *minus* the
> number of those seconds that were leap seconds in UTC. In the terms
> of POSIX, it returns the current POSIX time.
>
> This is a disastrous mistake.
I've looked into this, and I must say I concur wholeheartedly. I have
no idea what the committee was thinking when they came up with
POSIX time, but I can only assume they were under the influence of
some substance for which the idea of time passing at varying speeds
seems natural.
Since POSIX monotonic time is incapable of representing all second
intervals, additional information is required to disambiguate the leap
seconds - either a flag indicating whether the leap second has occurred
yet, or a count of all leap seconds, or TAI - and libraries like NTP add
these to workaround the broken POSIX time.
The bad news is that POSIX time overwhelmingly _is_ used in
isolation to represent time, in timestamps and network protocols
and filesystem access times, etc.
The good news is that if we have monotonic TAI time we can
easily and unambiguously convert to POSIX time when needed,
to get around any compatibility issues.
The ugly news is that if we standardize on TAI instead of POSIX
time then many Schemes may simply be unable to implement the
standard. You need a specialized library like NTP, or a hypothetical
clock_gettime with a CLOCK_TAI clock id. [CLOCK_MONOTONIC
is difficult to work with since the epoch is unknown, and is dangerous
on SMP systems because the process can shift to a different core
and get inconsistent results.]
I need to think about this more, but at this point am inclined to drop
any notion of time from WG1 and leave it to WG2.
--
Alex
_______________________________________________
Scheme-reports mailing list
Scheme-reports@x
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports