[Haskell-cafe] threadDelay delays less time than expected (Windows)
jo at durchholz.org
Thu Dec 29 22:27:58 UTC 2016
Am 29.12.2016 um 22:41 schrieb Bardur Arantsson:
> (Of course
> there must be *some* way to 'convert', but those conversions are
> inherently dangerous and should be clearly marked as such.)
Actually you don't convert, but you can add physical time to a calendar
It's not really dangerous, just complicated - leap years which follow a
rule, leap seconds that you have to look up in a table.
You don't do historic calendars; it's even dubious that you need Islamic
or other calendars unless you do either religious or historic dates, in
which case domain-specific code would probably be appropriate.
Leap seconds are "unsafe" in the IO sense: they occur at irregular times
and are not predictable, so this addition is not referentially transparent.
I can't think of a use case for this kind of addition in application
code though: Either you do calendar calculations, and then you add
calendar seconds to a date, with the usual 24:60:60 factors for
days/hours/minutes/seconds. Or you do timing-related code: timers that
go off, benchmarks, and in both cases you start with a timestamp and add
physical seconds, which is trivial.
(In system code, the NTP stack or some local driver needs to keep track
how physical time relates to calendar time, but that's nothing you'd
need or want in a standard library.)
tl;dr: physical time and calendar time are different concepts, have
different uses, and the use cases for mixing the two are so rare that
conversion code shouldn't go into any kind of standard library. IMHO.
>  Bascially before JodaTime made ordinary developers aware of just how
> complex this Time/Date stuff really is and the importance of clearly
> separating the concept of "calendar" time vs. "physical" time.
Yeah, that's a really awesome library, and well worth looking at if you
want fresh time API ideas.
More information about the Haskell-Cafe