Closed mbg closed 6 months ago
Hmm, could you give an example?
@AshleyYakeley: sure, I have a time format String
as follows:
timeFormat :: String
timeFormat = iso8601DateFormat (Just "%H:%M:%S%06Q")
I can format a given time :: UTCTime
using this (in GHCi):
λ formatTime defaultTimeLocale timeFormat time
"1970-01-01T00:00:00.000000"
Now I'd like to be able to parse a String
value like that back into a UTCTime
value, but I get a runtime error:
λ parseTimeM @IO @UTCTime True defaultTimeLocale timeFormat "1970-01-01T00:00:00.000000"
*** Exception: user error (parseTimeM: no parse of "1970-01-01T00:00:00.000000")
This seems to happen due to the %06Q
part of the formatting String
and lines up with what the documentation for parseTimeM
is describing as "padding widths are not supported".
If you omit the padding width when parsing, it will parse:
ghci> parseTimeM @IO @UTCTime True defaultTimeLocale (iso8601DateFormat (Just "%H:%M:%S%Q")) "1970-01-01T00:00:00.000000"
1970-01-01 00:00:00 UTC
That does indeed seem to work, thank you @AshleyYakeley!!
I don't see this mentioned in the documentation right now, but it might be a useful piece of information to include for parseTimeM
-- would you accept a PR which adds a sentence about this?
Is that really necessary?
The documentation for
parseTimeM
notes that "padding widths are not supported". I was wondering if there was any particular, technical reason for this (since the relevant code does not seem to have any comments explaining it) or if it has just not yet been implemented due to a lack of demand?If it is the former, it might be useful to document this somewhere. If it is the latter, this is one expression of "demand"! Time permitting, I could have a look at implementing it myself, but I am unfamiliar with the codebase and wanted to check that there wasn't a technical reason for its omission first.