Standard ISO8601 format for `LocalTime` is not padded

[andreasabel]

I am a bit surprised that the default format as in

iso8601Show <$> liftA2 utcToLocalTime getCurrentTimeZone getCurrentTime

prints 6 fractional second digits, but not padded with 0s.
E.g. using it in debug output, I can get:

2022-06-15T14:45:48.154887: computing generalization for type _20 (M = genTel)
2022-06-15T14:45:48.155189: we're generalizing over
2022-06-15T14:45:48.155919: created genRec
2022-06-15T14:45:48.51073: computing generalization for type _22 (M = genTel)
2022-06-15T14:45:48.51294: we're generalizing over _l_23
2022-06-15T14:45:51.834072: created genRec Issue5926._..generalizedField-l

This is unexpected, since omitting trailing 0s usually means that the measurement is less precise, e.g. 0.5 km isn't the same as 0.500 km as a physical quantity.

Why was it decided to drop trailing zeros? Maybe this decision can be revisited?

[AshleyYakeley]

How many digits should the output be padded to?

[andreasabel]

Well, as you see in the example, by default it prints 6 digits after the dot, so these should be filled up with 0s.

[AshleyYakeley]

That's not quite true. The format simply trims off all trailing zeros (out of a maximum of twelve).

This is what your output would look like without trimming trailing zeros:

2022-06-15T14:45:48.154887000000: computing generalization for type _20 (M = genTel)
2022-06-15T14:45:48.155189000000: we're generalizing over
2022-06-15T14:45:48.155919000000: created genRec
2022-06-15T14:45:48.510730000000: computing generalization for type _22 (M = genTel)
2022-06-15T14:45:48.512940000000: we're generalizing over _l_23
2022-06-15T14:45:51.834072000000: created genRec Issue5926._..generalizedField-l

Is this what you want?

[andreasabel]

Ok, this is interesting. I was lead to think that the precision was 6 fractional digits. But it seems that only getCurrentTime samples a max of 6 fractional digits (i.e., only measures as precisely as microseconds). I have no deeper knowledge of this, e.g. whether this is OS/Arch specific or not.

So the solution is rather to avoid the ISO8601 default format and give some more specific format making the number of fractional digits explicit.

I am closing this issue, thanking you for the enlightenment!