On 2005-10-31, Ashley Yakeley
Just in time for HCAR...
Please take a look at my second attempt at writing a replacement for the standard time library. http://semantic.org/TimeLib/
Thanks for your work on that. This is certainly a sore spot in Haskell right now. Your library looks very complete. It also looks over-complicated, IMHO. (Somewhat of the same problem that the current library has). There are just a few functions that a lot of people need, and they are: (C functions in parens) * Convert epoch time to a printable string (ctime) * Convert epoch time to something like struct tm (localtime/gmtime) * Convert a struct tm to epoch time (mktime) * Convert a struct tm to a printable string (asctime) * Get the current time in epoch seconds (time) It all seems overly-complicated to me, and it's not obvious how to do any of these things from the documentation. (Unlike, say, Python -- or even System.Time.) I am also concerned that you have separate types for UTCTime and LocalTime. Many people would consider UTC to be just another zone (Unix does, for instance.) I recognize that there are complicated issues surrounding timekeeping, but the average programmer should not have to worry about those details unless those details are relevant. (They usually are not) Perhaps the solution is a Data.Time.Simple or something that acts as a wrapper. For many programmers, myself included, the Unix epoch is the most common, pervasive, and useful way to work with time. Calculations are simple (no need for various TimeDiff sort of things -- just add on x number of seconds), and it is used *everywhere* in the OS, databases, etc. Something that is based on that, such as the C API, is a plus, IMHO. -- John