Ashley, heads up! I am CCing you on this message because I think a problem has been found with Data.Time.Format. Please see below. Daniel Patterson wrote:
I've found most of the time library to be quite useful, but the parsing to be worthless
The API for parsing and rendering time in Data.Time is based on the standard API for that in C - like the libraries in most languages. It's pretty standard stuff. I'm sure it can be improved upon though. If you have a useful alternative time parsing library, please release it on Hackage.
Specifically, the formatTime function, if it ever strips out padding (by zeros or spaces), results in a time that is unparseable. The fact that formatTime and parseTime are not capable of being inverses of each other seems like a major flaw,
Well, it is possible to render dates and times in a way that loses information, so you can't expect those to be complete inverses of each other.
when you think that this is not a parseable date: 2011/1/30 (because the month must be padded by zeros).
Hmm, that does seem wrong. The C API allows that to be parsed using the format "%Y/%m/%d", since the leading zero for %m and %d are optional when parsing. See, for example, http://pubs.opengroup.org/onlinepubs/009695399/functions/strptime.html I am including Ashley as a CC on this. Perhaps he will fix it. It looks like the function "parseValue" is wrong for the following format letters: "CdHIjmMSuwW". For each of those, "decimal n" should replaced by something that requires at least 1 digit and allows up to n. Then the various instances of ParseTime should be checked, but they should be OK because they all seem to use "read". Thanks, Yitz