Please use Haddock comment syntax for comments like there where it makes sense. (I’ve made the change here myself, since it’s a small thing, but just so you know in the future.)

FWIW I wrote a similar utility function in https://github.com/hasura/graphql-engine/pull/3622/files#diff-b4adc70671eae2d8ba4ad21bd16ede86R104 I considered NominalDiffTime but ultimately went a different route since having a duration type tagged with a unit is less error-prone when using literals and when serializing. But there are tradeoffs for both approaches...

I also use the monotonic clock, which is a more strictly correct way to get timing, but again this probably doesn't matter (unless some other part of the code blows up or loops on unexpected negative duration etc...)

@lexi-lambda @hgiasac actually I think I need an opinion here. I'm rebasing my PR again on this and now there's a block of code we time twice ) in two different ways which doesn't make much sense.

I'm okay refactoring to use NominalDiffTime (or maybe even better, a newtype called Seconds) as a standard duration type

@jberryman I wrote a library for doing type-safe unit conversion stuff in Data.Time.Clock.Units. It’s all based on DiffTime, though, not NominalDiffTime, since as you mention it’s the Right Thing here.

That said, I’ve never actually been 100% clear on how you’re supposed to actually get a DiffTime with the usual Data.Time.Clock API. As far as I can tell, it doesn’t expose a monotonic clock. There’s Data.Time.Clock.TAI, but there’s no guaranteed way to access a clock that produces an AbsoluteTime.

My preference would be to wrap GHC.Clock so that it produces a DiffTime and use that, along with the Data.Time.Clock.Units module mentioned above. Does that seem reasonable to you?

Oh cool, I looked but totally missed that module. It looks good!

Types help a lot but time is crazy; my understanding, which is probably not entirely correct:

• AbsoluteTime was defined to be an epoch time, to support the possibility of a correct difference operation (DiffTime); no ecosystem really developed out of these (or maybe there are some good libraries out there! I've only used timezone-olsen which uses completely separate types IIRC)
• NominalDiffTime (nominal in the sense of "it doesn't really work"?) was defined separately with much self-loathing to support the useful but formally nonsensical diffing of UTCTime (which as they note is only correct (or legally binding?) if the UTCTimes are earlier than a horizon of 6 months from when you perform the calculation...)
• I think there fundamentally is not a way to get AbsoluteTime as they define it from your machine without a table of leap seconds; POSIXTime is what we usually think of when we think of an epoch time but is, I think, approximate wrt leap seconds (...very unclear about this)
• the monotonic clock is orthogonal to all of this; it's just an API that gives you a ticking counter that only increases (the regular system clock can jump forward or backwards). afaiu a reading of the monotonic clock has no meaning; it's only good for measuring durations.

Sooooo ... (what were we talking about?)

My preference would be to wrap GHC.Clock so that it produces a DiffTime and use that, along with the Data.Time.Clock.Units module mentioned above. Does that seem reasonable to you?

I think either DiffTime or NominalDiffTime are equally valid to use as a duration type in that module, but NominalDiffTime is the one you can actually use in calculations with time moments (for better or worse). So we might want to consider using NominalDiffTime in your module, but I have no real opinion there and yes that sounds good!

@lexi-lambda also re. an algebra for time etc., I couldn't remember the name of this structure and had to email a colleague: https://ro-che.info/articles/2013-01-08-torsors

Oh I see you can get an AbsoluteTime with http://hackage.haskell.org/package/time-1.9.3/docs/Data-Time-Clock-System.html#v:systemToTAITime , but now I'm a more lost...