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 p19IMhdA005500 for ; Wed, 9 Feb 2011 19:22:43 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnsEAGJqUk1iilpIgWdsb2JhbACEHJJfjmMBCwkKGgMhiDCjPDyCF4RciQgBBAQBgSKDP3YEhH+KI4g8 X-IronPort-AV: E=Sophos;i="4.60,446,1291590000"; d="scan'208";a="87744517" Received: from nm9.bullet.mail.ne1.yahoo.com ([98.138.90.72]) by mail4-smtp-sop.national.inria.fr with SMTP; 09 Feb 2011 19:22:37 +0100 Received: from [98.138.90.54] by nm9.bullet.mail.ne1.yahoo.com with NNFMP; 09 Feb 2011 18:22:36 -0000 Received: from [98.138.89.244] by tm7.bullet.mail.ne1.yahoo.com with NNFMP; 09 Feb 2011 18:22:36 -0000 Received: from [127.0.0.1] by omp1058.mail.ne1.yahoo.com with NNFMP; 09 Feb 2011 18:22:36 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 547554.30899.bm@omp1058.mail.ne1.yahoo.com Received: (qmail 85421 invoked by uid 60001); 9 Feb 2011 18:22:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1297275755; bh=ieOHRgiKdbJ3okPkl57B89skrGIbAGWHjkk9D3E4RAI=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=aQ6Vm4uAdWhBzTMJAWPruFOQk51f6c2tBNg0vfXBsAqrPskqJC+uu/NcOYfiZsqzenAi1plQVWXl5qxWKM7YMrXCoq96Po7djZk3ds6+XYp2JfEIEP1APISrXmb123soF72eCHVfRwVvO40pe755Oaxl8Ifp7tPe+g1VoYJHrUQ= 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:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=xPhbAv/0CbfkOl/UkS1/1epgrdkp5Jen82uIuWdadUqBYlAbn7vpNWj6ISDPoKB41r5KefYVRQwZWUcEfJYILnsU1ysxU0PBg4LYpVKlAi7ZXaHO73woiPeIsuowqt3KYc3k4ESYkYFLR9/pKxGBivtrzMaDlcDodOt74Mzd9C4=; Message-ID: <909070.84855.qm@web111510.mail.gq1.yahoo.com> X-YMail-OSG: MCmNTlcVM1kfnbJt2HzBTvBzq21blWMBUvA.Mq823XJoRCc xYyfI.FJJEvqDiLPNmODjMyyij5C.xyPxPc5U3rF5rce13CwlANKYVAlvClN BJ2KTHLHD40CkO5onJGZR2.Cx761e0JwPY5P6Mh87fXUt0y5IcRLLZmy4kBr YEfEJ4P.KmdLE6vjENif18M_5khgrrhImd.g9seivtfPjeXz9usp5etOkHS7 VuFWY7rMVBYYyXON7RrdxAOXoCM7yO4RTXrI8hqGRIf8V5bd1zJ2ne0UXsEM MO04E6mGygrSqPxxyG8dDypt3pNutkSCkVar7n7fguGvuLOlUewww2LE0JI. zhNlfOgUhAWCHuIVs8lvMgeWS4PCyg2tMfFvZt4ClOqxquw9lAcdMGj2HwiR LbKUAnI0230Dm Received: from [213.205.70.199] by web111510.mail.gq1.yahoo.com via HTTP; Wed, 09 Feb 2011 10:22:35 PST X-Mailer: YahooMailClassic/11.4.20 YahooMailWebService/0.8.108.291010 Date: Wed, 9 Feb 2011 10:22:35 -0800 (PST) From: Dario Teixeira To: caml-list@inria.fr, Eric Cooper In-Reply-To: <20110209174648.GC14218@localhost> 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 p19IMhdA005500 Subject: Re: [Caml-list] Localising timestamps 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