On 29 December 2016 at 22:27, Joachim Durchholz <jo@durchholz.org> wrote:

 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.


Hmm, I dunno, "complicated" implies it's at least possible to define a function which correctly add physical times to calendar times, which isn't true - you can't reliably calculate the calendar time exactly 400*86400 seconds from now because the result depends on whether there's a leap second or not and they're not announced that far ahead of time. I really think "dangerous" is a better word, although the word "unsafe" might be more Haskellish.

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 to this. Note that the distinction goes all the way down to the OS - see the CLOCK_REALTIME and CLOCK_MONOTONIC options to https://linux.die.net/man/3/clock_gettime for instance, and there is similar functionality within Windows. Doing any kind of timing-based things with CLOCK_REALTIME (and derivatives) is kinda flawed because it can run slow and/or jump backwards if NTP is fiddling with it. CLOCK_MONOTONIC is the right thing to use for that.

OTOH sometimes I want to say "sleep for 50 seconds" and sometimes I want to say "sleep until the current (calendar) time is X". As the delay API doesn't currently support both of these, you have to do the unsafe conversion between calendar times and durations to do both kinds of sleep. Fortunately it's rare to care about waking up at a particular second 6 months into the future so this mostly works just fine.

Some of these thoughts are implemented here: https://hackage.haskell.org/package/alarmclock

Cheers,

David





 


[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

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.