ANN: Enhancements to timezone processing in Data.Time
gale at sefer.org
Thu May 20 17:16:41 EDT 2010
The new timezone-series and timezone-olson packages provide
enhancements to timezone processing in Haskell's time
These enhancements are related to the fact that the
Data.Time.TimeZone data type does not fully represent a
timezone - it only represents a specific clock setting for a
timezone, as is traditional for time APIs.
But that leads to a number of limitations, such as:
o For utcToLocalTime and localTimeToUTC, it is up to the
user to ensure that the TimeZone and time specified are
consistent with each other. These functions can give wrong
results if the specified clock setting was not actually in
effect at the specified moment in the given timezone.
o It is difficult to compute the amount of time between
two moments expessed in terms of the local clock, because
you need to know the history of clock changes that
happened in between.
o When a ZonedTime is constructed, it is up to the user to
ensure that its components are consistent with each other
and make sense.
o Given a ZonedTime, there is no way to construct another
ZonedTime for a different moment in the same timezone,
unless you know that the same clock setting is in effect
at the new moment.
Besides those issues - it's just nice to have a type that
truly models a timezone.
The timezone-series package introduces two new datatypes:
TimeZoneSeries, which represents a timezone with all of its
clock settings and when each is in effect, and
ZoneSeriesTime, which represents a moment within a specific
timezone. This package also includes variants of
utcToLocalTime and localTimeToUTC which take a
TimeZoneSeries instead of a TimeZone as parameter and always
give the correct result.
The timezone-olson package provides a pure Haskell parser
and renderer for binary Olson timezone files. That provides
an easy way to create rich TimeZoneSeries objects for most
of the timezones of the world on many platforms.
I have tried to write these packages in a way that is
consistent as much as possible with Data.Time - naming
conventions, providing expected services such as ParseTime
and FormatTime instances, etc.
These packages are distributed on Hackage under a BSD3
o These packages contain preliminary versions of the
software and should be considered highly
experimental. Expect there to be bugs, and do not rely on
any stability of the exposed interfaces at the moment.
o So far, there is no easy solution for Windows users to
create a TimeZoneSeries. On Windows, timezone series
information is in the registry in a propreitary format,
and I don't have a parser for that at the moment. In the
meantime, Windows users can copy the Olson files from a
Unix system, or compile the Olson files themselves from
the zoneinfo sources. I hope to have a much better
solution in the near future, and, of course, contributions
o There is not yet a truly platform-independent way of
finding the Olson files for Unix-like platforms. Nowadays
/usr/share/zoneinfo is a very popular location for them,
but some platforms have them elsewhere.
o getCurrentTimeZone is still the best way to get the
"official" clock setting for the current moment on the
local computer for the local time zone, or for whatever
time zone you fool the OS into thinking that you are
in. There is also Mark Aylett's zoneinfo package. Those
bindings to the C API give you clock settings that are
most likely to be consistent with what is used by other
apps on the same local computer.
But the C API gives you a clock setting, not a timezone.
And the system timezone database on the local computer could
be out of date. And the interface, which involves setting
global process state and then calling effectful procedures,
is awkward to say the least and prone to cause trouble. So
I think it's nice to have a pure Haskell Olson parser.
I would like to take this opportunity to thank once again
Ashley Yakely for his fantastic work in creating Haskell's
advanced time API in Data.Time.
More information about the Libraries