RFC: Time Library 0.2

[Sebastian Sylvan]

On 11/1/05, John Goerzen <jgoerzen at complete.org> wrote:
> On 2005-10-31, Ashley Yakeley <ashley at semantic.org> wrote:
> > 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.
>

I'll just add in another feature request.

I sometimes need wall-clock time with very high precision. To meassure
the time it takes to run a function say. CPUTime does some of that,
but that only meassure the amount of time you use on the CPU, it would
be nice to know in "real" time how long it's been between two times.
You could use a PerformanceCounter on windows and I'm sure there is
something similar on other architectures.

SDL has a library which does something like this, unfortunatly they
return milliseconds, which is several orders of magnitude less
resolution than most internal timers really have. So an Integer (or
Int64) returning picosecs (since system boot, program start or
something like that) is probably a good somewhat future-proof
solution.

/S


--
Sebastian Sylvan
+46(0)736-818655
UIN: 44640862