[Caml-list] Localising timestamps

[Caml-list] Localising timestamps

[Dario Teixeira]

Hi,

I have a problem which is fairly common when one is running a web application
that wishes to display timestamps localised towards each user's time zone.
Basically, I need a function that takes as input a timestamp in UTC and a
time zone specified in the Zoneinfo [1] convention (ex: "Europe/Lisbon"),
and returns the localised version of that timestamp, including a time zone
abbreviation aware of daylight savings.  Example:

2010-01-01 15:30, "Europe/Lisbon"       -> 2010-01-01 15:30 WET
2010-01-01 15:30, "Europe/Paris"        -> 2010-01-01 16:30 CET

2010-07-01 15:30, "Europe/Lisbon"       -> 2010-07-01 16:30 WEST
2010-07-01 15:30, "Europe/Paris"        -> 2010-07-01 17:30 CEST

Since the zoneinfo data is present in every Unix system and glibc includes
routines for parsing it, interfacing with glibc seemed the obvious solution.
Unfortunately, glibc was not designed with this use case in mind.  In fact, 
the glibc interface to zoneinfo can be described as "sui generis" if one
is feeling charitable, or "insane" if truth must be told.  Specifically, to
obtain the localised version of a given timestamp, one must first set the 'TZ'
environment variable with the target timezone, and then invoke 'localtime'. 
The abbreviated name of the timezone can be found in the global 'tzname'
array: at position 'tzname[0]' if daylight savings are not in effect and at
position 'tzname[1]' if they are.  A quick search through glibc's bugzilla
shows I'm not the only one to find this interface anachronistic [2], but it
also reveals that it is unlikely to change.

So, my question is if someone is aware of some alternative library (C/C++,
so it's easy to build the FFI for it) that provides this same functionality.
Janestreet's Core seems to include a native parser of zoneinfo data, but
it's also tightly integrated with the rest of Core, which may make plundering
this code problematic. Ideally, these routines should at some point be part
of Calendar or Batteries -- are there plans to include them?

Best regards,
Dario Teixeira

[1] http://en.wikipedia.org/wiki/Tz_database
[2] http://sources.redhat.com/bugzilla/show_bug.cgi?id=11620



      

Re: [Caml-list] Localising timestamps

[Eric Cooper]

On Wed, Feb 09, 2011 at 07:34:39AM -0800, Dario Teixeira wrote:
> Basically, I need a function that takes as input a timestamp in UTC and a
> time zone specified in the Zoneinfo [1] convention (ex: "Europe/Lisbon"),
> and returns the localised version of that timestamp, including a time zone
> abbreviation aware of daylight savings.

This might not meet your performance requirements, but it's certainly
easy to program with Unix.process_open etc.

$ TZ=Europe/Paris date --date="2010-07-01 15:30 UTC" +"%F %T %Z"
2010-07-01 17:30:00 CEST

The built-in date parser is quite powerful.

-- 
Eric Cooper             e c c @ c m u . e d u

Re: [Caml-list] Localising timestamps

[Dario Teixeira]

Hi,

> This might not meet your performance requirements, but it's
> certainly
> easy to program with Unix.process_open etc.
> 
> $ TZ=Europe/Paris date --date="2010-07-01 15:30 UTC" +"%F
> %T %Z"
> 2010-07-01 17:30:00 CEST
> 
> The built-in date parser is quite powerful.

Currently I'm using glibc's routines accessed via a small C stub, since
Ocaml's Unix library does not give direct access to the 'tzname' array [1].
I'm avoiding the concurrency issues related to setting the TZ environment
variable only because the web application is written using Ocsigen and
thus also Lwt, allowing me control when there is a switch to another thread.
Nevertheless, this mechanism of changing a global TZ variable to affect
the behaviour of a function is ugly and error-prone.  Hence why I'm
looking for a purely functional solution.

Ironically, glibc already includes all the code to make the zoneinfo
parsing, and it's a pity that it does not expose it to userspace in a
more flexible manner (and yes, I realise there is probably some POSIX
mandate that justifies this broken interface).  I'm beginning to
understand why the Debian folks switched to eglibc...

Anyway, apparently what is happening at the moment is that any applications
with similar requirements to mine just duplicate and adapt the relevant code
from glibc.  Postgresql is doing this, for example.  

Cheers,
Dario

[1] http://caml.inria.fr/mantis/view.php?id=5063