SecondOfDay and MinuteOfDay types

[NorfairKing]

I'm running into this bug: yesodweb/persistent#1500 and I realise that actually I don't need sub-second or even sub-minute precision.

Perhaps time could have SecondOfDay and MinuteOfDay types that avoid this problem by construction.

[AshleyYakeley]

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?

[NorfairKing]

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

[AshleyYakeley]

OK, but what actually happened that caused the problem?

[NorfairKing]

@AshleyYakeley I'm not sure. I'm guessing an upgrade somewhere but I can't tell of which package: time/sqlite/persistent...

[AshleyYakeley]

OK. Well let's leave this open, see if anyone has a real-world use-case for it.

[NorfairKing]

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

[AshleyYakeley]

Can you tell me why it's not round-tripping?

[AshleyYakeley]

Which way are you going, sqlite→TimeOfDay→sqlite, or TimeOfDay→sqlite→TimeOfDay? And if the latter, how are you constructing the initial TimeOfDay?

[NorfairKing]

@AshleyYakeley it's the latter.
genValid :: Gen TimeOfDay -> (this part is "wrong" but it's baked into persistent) sqlite -> TimeOfDay

[AshleyYakeley]

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.