
sent from wrong account - message follows:
I've found most of the time library to be quite useful, but the parsing to be worthless (I've tried to get someone to prove me wrong already, and would be happy if someone could on this thread!).
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, when you think that this is not a parseable date:
2011/1/30 (because the month must be padded by zeros).
Even though it is very easy to print, and occurs commonly in the world.
Because of this, I use formatTime to write my times, and then have a custom parser to parse them back out. Which makes me think that this is a broken library
On Jun 27, 2011, at 10:37 AM,
wrote: On Mon, 27 Jun 2011 11:15:28 +0300 Yitzchak Gale
wrote: The biggest shortcoming, in my opinion, is that the documentation assumes that the reader is very familiar with the Haskell type system, and with viewing type signatures and instance lists as an integral and central part of the documentation.
In particular, Haskell's standard numeric type classes and the conversion functions between them play a central role in the API of Data.Time. But you wouldn't realize that unless you have read the type signatures and instance lists in the Haddocks very carefully, and have thought about it for a while.
This is exactly right.
Another problem, as Malcolm pointed out, is that because of the sheer size of the library, a quick-start guide for the common cases would be extremely helpful for newcomers.
That would be very, very helpful. I had a few working examples things were much better. Finding a starting place, any starting place, proved to be quite elusive. Also the fact that asking for the current time traps you in IO hell, doesn't help, although it's clear that it should be that way.
Brian
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

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

On 2011-07-02 13:22, Yitzchak Gale wrote:
Ashley, heads up! I am CCing you on this message because I think a problem has been found with Data.Time.Format.
Thanks Yitzchak.
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
This was fixed in time-1.2.0.5. From the haddock for parseTime: "Supports the same %-codes as formatTime, including %-, %_ and %0 modifiers." With ghci: Prelude System.Locale Data.Time> parseTime defaultTimeLocale "%Y/%-m/%-d" "2011/1/30" :: Maybe Day Loading package old-locale-1.0.0.2 ... linking ... done. Loading package time-1.2.0.5 ... linking ... done. Just 2011-01-30 -- Ashley Yakeley

Ashley Yakeley wrote:
This was fixed in time-1.2.0.5. From the haddock for parseTime:
"Supports the same %-codes as formatTime, including %-, %_ and %0 modifiers."
Great, glad to hear this was recently fixed. I installed the latest version of the time package, and it works. It is important to note that this works differently than the usual strptime behavior, though. For example, "%m" in Data.Time is an alias for "%0m", whereas "%m" in strptime means the same as "%-m" in Data.Time (optional leading zero). Thanks, Yitz

On 2011-07-02 16:35, Yitzchak Gale wrote:
It is important to note that this works differently than the usual strptime behavior, though. For example, "%m" in Data.Time is an alias for "%0m", whereas "%m" in strptime means the same as "%-m" in Data.Time (optional leading zero).
I made some changes from the C lib behaviour for consistency. In C, "%m" means "%0m" in strftime and "%-m" in strptime. I decided to make it "%0m" consistently. Also, at least in glibc, the %# modifier does not consistently convert to lower case. In Data.Time it does. -- Ashley Yakeley

Yitzchak Gale wrote:
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.
In the perl world, there is a Date::Parse library that I have found very useful in many situations. It can parse any date format you throw at it, fairly reliably[1]. The closest I have in Haskell is the attached module, which I used to parse all dates in all Usenet posts between 1981 and 1991. While small portions are specific to Usenet messages it does have quite a lot of generic parsing code, and perhaps most usefully, a large number of date format strings, and I have thought about making a library if I find time. (Or anyone is welcome to take it and do so.) It's based on Data.Time.Parse instead of Data.Time.Format.parseTime, probably because I didn't notice the latter when I was writing it. -- see shy jo [1] m/d/y vs d/m/y being the main weakness of course
participants (4)
-
Ashley Yakeley
-
Daniel Patterson
-
Joey Hess
-
Yitzchak Gale