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 _______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
