Closed NorfairKing closed 5 months ago
Hmm, could be useful.
Leaving aside the principle of not representing disallowed state, the more practical advantage of these types over TimeOfDay
would be Read
and Show
instances, is that correct? Is this what caused the issue with persistent/sqlite?
@AshleyYakeley I know we differ in opinion about this, so I won't argue about it.
What caused the issue with persistent/sqlite is that persistent/sqlite doesn't represent sub-second precision but TimeOfDay
does.
OK, but what actually happened that caused the problem?
@AshleyYakeley I'm not sure. I'm guessing an upgrade somewhere but I can't tell of which package: time
/sqlite
/persistent
...
OK. Well let's leave this open, see if anyone has a real-world use-case for it.
@AshleyYakeley I've already had a real-world use-case in https://social-dance.today.
TimeOfDay
doesn't roundtrip through sqlite so I needed to use SecondOfDay
.
Can you tell me why it's not round-tripping?
Which way are you going, sqlite→TimeOfDay
→sqlite, or TimeOfDay
→sqlite→TimeOfDay
? And if the latter, how are you constructing the initial TimeOfDay
?
@AshleyYakeley it's the latter.
genValid :: Gen TimeOfDay
-> (this part is "wrong" but it's baked into persistent
) sqlite
-> TimeOfDay
I think this is better left for another package to do. It would introduce a lot of additional conversion functions, and generally I want to keep time
focussed on time-related calculations rather than precise conceptual abstraction.
I'm running into this bug: https://github.com/yesodweb/persistent/issues/1500 and I realise that actually I don't need sub-second or even sub-minute precision.
Perhaps
time
could haveSecondOfDay
andMinuteOfDay
types that avoid this problem by construction.