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