From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id p19FYhvb031433 for ; Wed, 9 Feb 2011 16:34:43 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqwRAI1CUk1ii1vZWmdsb2JhbACEHJJbMY4nARYVBhEEIawfPIIXhESJCAEEBAGBIoM/dgSEf4oj X-IronPort-AV: E=Sophos;i="4.60,446,1291590000"; d="scan'208";a="87734174" Received: from nm19-vm1.bullet.mail.sp2.yahoo.com ([98.139.91.217]) by mail4-smtp-sop.national.inria.fr with SMTP; 09 Feb 2011 16:34:41 +0100 Received: from [98.139.91.64] by nm19.bullet.mail.sp2.yahoo.com with NNFMP; 09 Feb 2011 15:34:40 -0000 Received: from [98.139.91.36] by tm4.bullet.mail.sp2.yahoo.com with NNFMP; 09 Feb 2011 15:34:40 -0000 Received: from [127.0.0.1] by omp1036.mail.sp2.yahoo.com with NNFMP; 09 Feb 2011 15:34:40 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 194392.23175.bm@omp1036.mail.sp2.yahoo.com Received: (qmail 53429 invoked by uid 60001); 9 Feb 2011 15:34:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1297265679; bh=fZMt4hu1IcGLY6LdUnbrFDxfNH7aYJXF3XhaI96M4r0=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=DCf5suzXgk9DPUYqeqi9hdXc9OAgLuauYd7i92gXQ8mUqbUfsZc3qRinejSErbsK4i2/USQGEAEF38SprYbjKNv+lA6aw4e1OyM3dGdEp8/+ks1O2P5XDbpXQ352my7gqNGFFPC3Jt9ukw+iPgkVmRJIrIYe0XwwRBy/rhIVT0U= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=nOWjZPZnRKTz8RKC5NpKVj7KbmLALiUZ00PpQifZ7hwUnJx+ORkVw9z5MHIdoFZyseQQQA5E6vJv8Ab8JFyfjEx1R9wZjvvvZdjzk460YqEClUb6sqwup/nzL7XtmpCV1ZCvPW+QnEfzDV+QKUD637hrXJROm3pHGxpde6SDPts=; Message-ID: <670846.47961.qm@web111516.mail.gq1.yahoo.com> X-YMail-OSG: 9LTQtK0VM1nZI2k5y6jSAvSgcfx70w3wqWEK5JEbRH9zj2D 7ALpxrEhbNFnIrVtaGZ4RZwCbhJK5xBwJExWowBkCKgKrwmVS9maXqD9o2g1 PPVImpObkjga17VDSFUEyWSYoqhr_wPpg0sRCaYnUECnJxk3KKEoU14JAtbB SkIF2zJamPOJNrqrBPWpi.BdbLJm558vxU.uHdVS1lv4bgjuSJ7LzALzfrRN CMO1CHEVuqiT.xAFPSVxz83EpF6Su4MJpKFzrzoP8Hnt2eQR_MuQA5eBx_1p drlKo3RzzgTTltD1pZvSmH2jyMQ0pgkEOolsnh2Bwh8mr2_Qv_aOj615hGgP HWxiXIIUacvCtQNeD87WJ6FEwvld3tajbrmhwYGmaHW7D1IwRIrNy7J5vQv5 UNhy.MpyxYc6J Received: from [213.205.70.199] by web111516.mail.gq1.yahoo.com via HTTP; Wed, 09 Feb 2011 07:34:39 PST X-Mailer: YahooMailClassic/11.4.20 YahooMailWebService/0.8.108.291010 Date: Wed, 9 Feb 2011 07:34:39 -0800 (PST) From: Dario Teixeira To: caml-list@inria.fr MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by walapai.inria.fr id p19FYhvb031433 Subject: [Caml-list] Localising timestamps 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