On Tue, Dec 14, 2010 at 8:06 AM, John Cowan <cowan@mercury.ccil.org> wrote:
> Alex Shinn scripsit:
>
>> I have no idea what the [ISO C] 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.
>
> They were under the influence of the maxim "Existing code matters,
> existing implementations do not".  They observed that the overwhelming
> majority of existing applications code that made use of clock() assumed
> that {leap years, non-leap years, days, hours, minutes} were exactly
> {31622400s, 31536000s, 86400s, 3600s, 60s} long.  Therefore, they defined
> clock() to return a notion of time with the same assumptions.

And that code is more important than the code that assumed 1s = 1s?
You have breakage either way.

The truth is that a day is _not_ 86400s long, any more than a year
is 365 days, and code that makes this assumption is just as broken
as code which ignores leap years (of which there is no doubt a
plethora of examples).

But even if their solution somehow didn't break any existing code,
this is a case where the cure is worse than the disease.  The most
important thing is representation - to unambiguously represent any
datetime (within some granularity <= 1s, within some range).  POSIX
monotonic time gives us no way to do this.  For me to consider a
WG1 time proposal seriously it would need to provide a way to
work around this.

--
Alex

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