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

On Saturday, July 2, 2011, Joe Healy wrote:

One of the points I found "non obvious" were the fact that local time is just that. There is no knowledge of the actual timezone in the data type. If you wish to store that, it needs to be stored alongside.

Isn't that what ZonedTime [1] is for? [1] http://hackage.haskell.org/packages/archive/time/1.1.4/doc/html/Data-Time-Lo... Erik

I've attached my test program in the hope that it will be useful for someone (or if it is bad, get some help). Is there somewhere/way to contribute some examples or documentation?  I feel the time home page (http://semantic.org/TimeLib/) makes the library feel more experimental than it really is.

Cheers,

Joe

On Mon, 2011-06-27 at 07:37 -0700, briand@aracnet.com 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

Joe Healy wrote:

...

One of the points I found "non obvious" were the fact that local time is just that. There is no knowledge of the actual timezone in the data type. If you wish to store that, it needs to be stored alongside.

Erik Hesselink wrote:

Isn't that what ZonedTime [1] is for?

Not exactly. A "TimeZone" in Data.Time doesn't really represent a time zone - it represents a specific clock setting in a time zone. Clock settings periodically change in a time zone - e.g., to or from summer time, or due to government decree. A ZonedTime is a LocalTime together with a specific clock setting in a time zone. There is no guarantee that the clock setting was actually in effect at the given LocalTime. So a ZonedTime is only useful if you have checked separately that it is consistent, or if you don't care. ZoneSeriesTime in the timezone-series package[1] more accurately represents a moment in time in a given time zone. There the moment is represented as a UTCTime, not a LocalTime. The reason is that a LocalTime in a time zone does not necessarily represent a unique moment. When the LocalTime happens to be near a clock change, it can represent zero moments or more than one moment. To get the LocalTime from a ZoneSeriesTime, use the function zoneSeriesTimeToLocalTime. To get a TimeZoneSeries, representing a time zone with all of its known clock changes throughout history and some years into the future, use the timezone-olson package[2] to read an Olson time zone file. On Linux and Mac OS X systems, Olson time zone files are available in the directory /usr/share/zoneinfo. -Yitz

On 2 Jul 2011, at 22:13, Yitzchak Gale wrote:

[1]http://hackage.haskell.org/package/timezone-series [2]http://hackage.haskell.org/package/timezone-olson

I'd just like to add that these timezone packages are fantastic. They are extremely useful if you need accurate conversion between wall-clock times in different locations of the world, at arbitrary dates in the past or future, taking account of the differing moments at which daylight savings times take effect and so on. [At least one financial institution is now using them to avoid losing money that might otherwise happen due to confusion over the exact time of expiry of contracts.] Thanks Yitz. Regards, Malcolm

I wrote:

...

Not exactly. A "TimeZone" in Data.Time doesn't really represent a time zone - it represents a specific clock setting in a time zone.

Ashley Yakeley wrote:

I still regret this! I should have called it TimeOffset or somesuch.

Oh, it's not your fault. Every other time library in the world calls that a "time zone". You've gotten so many other more substantial things right that so many others got wrong. This name is nothing to worry about.

...

To get a TimeZoneSeries, representing a time zone with all of its known clock changes throughout history and some years into the future, use the timezone-olson package[2] to read an Olson time zone file. On Linux and Mac OS X systems, Olson time zone files are available in the directory /usr/share/zoneinfo.

Leap second data is there too, so it should be possible to create a Data.Time.Clock.TAI.LeapSecondTable from it.

No, unfortunately. There is a place in the data structure for leap second information, but no live Olson file has every populated it AFAIK. That's not so important though. There have been very few leap seconds in history, and they occur rarely. Their release cycle has been slower than the usual release cycle of software packages. So this is something that could easily be done manually.

Also, it might be worth creating an OS-specific package that dealt with the filepaths for you, so for instance you could read in a TimeZoneSeries given a time zone name such as America/Los_Angeles.

That would be nice. Perhaps a higher priority would be to add support for Windows, where the Olson data is in the registry rather than in the file system. Right now, people on Windows are still dependent on asking a favor from their friends to lend them copies of the latest Olson files. Another important enhancement would be support for POSIX rules. Olson files still supply explicit clock changes for about two decades into the future. But I believe that will gradually end now that the new Olson file format supports POSIX rules for clock changes beyond the last one explicitly specified. (And besides being supported, recently released Olson files actually do contain the POSIX rules. So does the Windows registry.) Thanks, Yitz