[Haskell-cafe] threadDelay delays less time than expected (Windows)

[Joachim Durchholz]

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 
date.
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.

> [1] 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.

Regards,
Jo