On Tue, Dec 14, 2010 at 8:06 AM, John Cowan <cowan@x> 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@x
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports