Tony Morris wrote:
I recently set out to write a library that required a decent time library. Having only had a flirt with Data.Time previously, I assumed it would be robust like many other haskell libraries. I don't know about consensus, but I have been massively let down. I won't go in to the details...
Data.Time is in some ways like Haskell itself. Though at first glance it seems a little daunting, in reality its semantic correctness makes it easier to use, not harder, than any of its alternatives in any language that I know (and I am proficient in quite a few). Once you have caught on, it is difficult to settle for anything less. 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. 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. What other issues have you noticed?
is there a reasonable alternative to Data.Time If I am right, and there is no alternative, I see no option but to take an excursion into writing my own.
No. There are several alternatives, but I have never seen anything that has come close to Data.Time. Before you undertake writing a whole new time library, why not try writing some improved documentation for Data.Time first? I think that would give the most immediate benefit to the community, and I'm sure it would improve the quality of whatever library of your own you end up writing. Regards, Yitz