On 11/1/05, John Goerzen wrote:

On 2005-10-31, Ashley Yakeley 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

On 11/1/05, Bulat Ziganshin wrote:

Hello Sebastian,

Tuesday, November 01, 2005, 5:21:44 PM, you wrote:

SS> I sometimes need wall-clock time with very high precision. To meassure

i use the following:

diffTimes (TOD sa pa) (TOD sb pb) = fromIntegral(sa - sb) + (fromIntegral(pa-pb) / 1e12)

-- Number of seconds since oprogram start return_real_secs = do start_time <- readIORef refClockTimeAtProgramStart current_time <- getClockTime return $ diffTimes current_time start_time

of course, it's a hack using internal details of current library and i also need the function which will return high-precision wall-clock time

Well, on my system, System.Time has a resolution of 16ms, which is terrible. So we need a function that uses the various high performance counters that each architecture exposes to get high-precison results. /S -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862

On 11/1/05, Tony Finch wrote:

On Tue, 1 Nov 2005, Sebastian Sylvan wrote:

...

Well, on my system, System.Time has a resolution of 16ms, which is terrible.

So we need a function that uses the various high performance counters that each architecture exposes to get high-precison results.

Those counters are not synchronized to civil time. You can't have both high resolution and absolute precision.

Which is why I requested a separate function which just gives the picosecs since startup (or something). -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862

On 11/2/05, Ashley Yakeley wrote:

In article <3d96ac180511010738h1e3c5206vba7318e724e3cb48@mail.gmail.com>, Sebastian Sylvan wrote:

...

Which is why I requested a separate function which just gives the picosecs since startup (or something).

That's what getCPUTime in System.CPUTime does.

No it isnt'. getCPUTime gives the.. uh.. CPU-time :-) If all my program does is sleep, waiting for other programs to release some resource, then getCPUTime will return zero. What I'm requesting is a function which gives the number of wall-clock picos seconds since startup, which could be used for all sorts of real-time simulations etc. /S -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862

On Wed, Nov 02, 2005 at 08:19:56PM -0800, John Meacham wrote:

On Wed, Nov 02, 2005 at 11:43:16AM +0100, Sebastian Sylvan wrote:

...

On 11/2/05, Ashley Yakeley wrote:

...

In article <3d96ac180511010738h1e3c5206vba7318e724e3cb48@mail.gmail.com>, Sebastian Sylvan wrote:

...

Which is why I requested a separate function which just gives the picosecs since startup (or something).

That's what getCPUTime in System.CPUTime does.

No it isnt'. getCPUTime gives the.. uh.. CPU-time :-)

If all my program does is sleep, waiting for other programs to release some resource, then getCPUTime will return zero.

What I'm requesting is a function which gives the number of wall-clock picos seconds since startup, which could be used for all sorts of real-time simulations etc.

is this true? I always thought that is what getCPUTime was supposed to mean, a reading from the tsc on x86 machines for instance and distinct from the unix notion of 'cputime'.

hmm.. looking at the report, you are correct. hmm.. perhaps we need another function to read the tsc-equivalent on various CPUs. -- John Meacham - ⑆repetae.net⑆john⑈