From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id 423F1BBAF for ; Sun, 7 Mar 2010 19:12:29 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AigDAHt7k0vRVd2+i2dsb2JhbACablAIFQEBAQoLCgcRBR8+twqEeASDFw X-IronPort-AV: E=Sophos;i="4.49,598,1262559600"; d="scan'208";a="58339027" Received: from mail-qy0-f190.google.com ([209.85.221.190]) by mail4-smtp-sop.national.inria.fr with ESMTP; 07 Mar 2010 19:12:28 +0100 Received: by qyk28 with SMTP id 28so4952394qyk.14 for ; Sun, 07 Mar 2010 10:12:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.226.76 with SMTP id iv12mr1670247qcb.7.1267985546559; Sun, 07 Mar 2010 10:12:26 -0800 (PST) X-Originating-IP: [63.203.46.196] In-Reply-To: <28fa90931003071005o5fdf17a0t3acbb87e826a1744@mail.gmail.com> References: <28fa90931003060153y5c4d1590j97fcc0267ee2dc1e@mail.gmail.com> <4B931D24.6050700@ramenlabs.com> <28fa90931003071005o5fdf17a0t3acbb87e826a1744@mail.gmail.com> Date: Sun, 7 Mar 2010 10:12:26 -0800 Message-ID: <28fa90931003071012i2e29ec77o1591977a325e4c6f@mail.gmail.com> Subject: Re: [Caml-list] Ocaml can't convert a GMT time into a float! From: Luca de Alfaro To: Dave Benjamin Cc: Inria Ocaml Mailing List Content-Type: multipart/alternative; boundary=0016364ecae01540ac048139e4c7 X-Spam: no; 0.00; ocaml:01 bug:01 ocaml:01 mktime:01 isdst:01 bug:01 mktime:01 camlprim:01 struct:01 val:01 val:01 yday:01 isdst:01 bool:01 alloc:01 --0016364ecae01540ac048139e4c7 Content-Type: text/plain; charset=ISO-8859-1 Sorry: wrong link. The code is here: http://luca.dealfaro.org/converting-gmt-time-into-unix-time-in-ocaml On Sun, Mar 7, 2010 at 10:05 AM, Luca de Alfaro wrote: > Thanks to all! > > I see, I am glad there are good alternative libraries! > For my problem, I preferred to avoid having dependence on one more library > for only 10 lines of code, so I wrote some code to do the conversion. It > works only for dates after 1970, and it is somewhat inelegant; it is here: > http://wghstrfg.blogspot.com/2010/03/i-hate-daylight-savings-time.html > > If you want to know why this bug drove me crazy for a couple of evenings, > you can read this blog post > . > > Many thanks, and I am glad my email helped Dave. > > Daylight savings time is a huge headache for anyone working on > historically-timestamped data. > > All the best, > > Luca > > > On Sat, Mar 6, 2010 at 7:27 PM, Dave Benjamin wrote: > >> Luca de Alfaro wrote: >> >>> I need to convert a time, expressed in yyyy/mm/dd hh:mm:ss form, into a >>> floating point. >>> The conversion has to be done in GMT, but the real point is, the >>> conversion must NOT change due to daylight savings time. >>> >>> Ocaml seems to have only one conversion function, however: Unix.mktime, >>> which takes a time, and makes a float in the local time zone. >>> >>> No problem, I thought: I will simply add 3600 if the conversion result >>> tells me that dst is active (and then convert for the difference between GMT >>> and winter time). >>> NO! This does not work! Look at the two conversions below. The tmrec >>> differs by one hour. >>> However, the two floating point numbers returned are identical, and >>> tm_isdst is set to true in both cases! >>> >>> This means that I have no way of using the standard libraries to convert >>> a time expressed in yyyy/mm/ss hh:mm:ss to a float! >>> >> >> You are absolutely right, and I unfortunately did not notice this subtlety >> when I wrote the XmlRpcDateTime module that is part of XmlRpc-Light, so this >> means there is a bug in XmlRpcDateTime.to_unixfloat_utc on systems with time >> zones that observe daylight savings. I did not notice the problem because I >> live in Arizona, one of only two states in the US that do not observe >> daylight savings! >> >> The culprit can be seen here in the C implementation of Unix.mktime: >> >> CAMLprim value unix_mktime(value t) >> { >> struct tm tm; >> time_t clock; >> value res; >> value tmval = Val_unit, clkval = Val_unit; >> >> Begin_roots2(tmval, clkval); >> tm.tm_sec = Int_val(Field(t, 0)); >> tm.tm_min = Int_val(Field(t, 1)); >> tm.tm_hour = Int_val(Field(t, 2)); >> tm.tm_mday = Int_val(Field(t, 3)); >> tm.tm_mon = Int_val(Field(t, 4)); >> tm.tm_year = Int_val(Field(t, 5)); >> tm.tm_wday = Int_val(Field(t, 6)); >> tm.tm_yday = Int_val(Field(t, 7)); >> tm.tm_isdst = -1; /* tm.tm_isdst = Bool_val(Field(t, 8)); */ >> clock = mktime(&tm); >> if (clock == (time_t) -1) unix_error(ERANGE, "mktime", Nothing); >> tmval = alloc_tm(&tm); >> clkval = copy_double((double) clock); >> res = alloc_small(2, 0); >> Field(res, 0) = clkval; >> Field(res, 1) = tmval; >> End_roots (); >> return res; >> } >> >> The field tm.tm_isdst is not really a boolean from C's perspective. It can >> be one of *three* states: positive for DST, zero for non-DST, and negative >> to query the system timezone database for the value. It looks like at one >> point Unix.mktime was written to take the value you gave it, but this was >> commented out and the value was fixed to -1. This is why it uses the time >> zone's daylight savings correction regardless of what you pass in. >> >> Would it be possible to have a new function in the standard library with >> the commented-out behavior instead? As it stands now I don't see any >> reasonable way to get a UTC float from a Unix.tm. >> >> As far as XmlRpc-Light is concerned, I will probably rewrite this function >> in terms of Netdate, since Ocamlnet is already one of my dependencies. >> Apologies to anyone who is affected by this bug (hopefully, no one). >> >> Thanks, >> Dave >> > > --0016364ecae01540ac048139e4c7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sorry: wrong link.=A0 The code is here: http://luca.dealfaro.org/conv= erting-gmt-time-into-unix-time-in-ocaml

On Sun, Mar 7, 2010 at 10:05 AM, Luca de Alfaro <luca@dealfaro.org> wrote:
=
Thanks to all!

I see, I am glad there are good alternative librarie= s!
For my problem, I preferred to avoid having dependence on one more l= ibrary for only 10 lines of code, so I wrote some code to do the conversion= .=A0 It works only for dates after 1970, and it is somewhat inelegant; it i= s here: http://wghstrfg.blogspot.com/2010/03/i-ha= te-daylight-savings-time.html

If you want to know why this bug drove me crazy for a couple of evening= s, you can read this blog post.

Many t= hanks, and I am glad my email helped Dave.

Daylight savings time is a huge headache for anyone working on historic= ally-timestamped data.

All the best,
Luca


On Sat, Mar 6, 2010 at 7:27 PM, Dave Benjamin <dave@ramenlabs.com>= wrote:
Luca de Alfa= ro wrote:
I need to convert a time, expressed in yyyy/mm/dd hh:mm:ss form, into a flo= ating point.
The conversion has to be done in GMT, but the real point is, the conversion= must NOT change due to daylight savings time.

Ocaml seems to have only one conversion function, however: Unix.mktime, whi= ch takes a time, and makes a float in the local time zone.

No problem, I thought: I will simply add 3600 if the conversion result tell= s me that dst is active (and then convert for the difference between GMT an= d winter time).
NO! This does not work! =A0Look at the two conversions below. =A0The tmrec = differs by one hour.
However, the two floating point numbers returned are identical, and tm_isds= t is set to true in both cases!

This means that I have no way of using the standard libraries to convert a = time expressed in yyyy/mm/ss hh:mm:ss to a float!

You are absolutely right, and I unfortunately did not notice this subtlety = when I wrote the XmlRpcDateTime module that is part of XmlRpc-Light, so thi= s means there is a bug in XmlRpcDateTime.to_unixfloat_utc on systems with t= ime zones that observe daylight savings. I did not notice the problem becau= se I live in Arizona, one of only two states in the US that do not observe = daylight savings!

The culprit can be seen here in the C implementation of Unix.mktime:

CAMLprim value unix_mktime(value t)
{
=A0struct tm tm;
=A0time_t clock;
=A0value res;
=A0value tmval =3D Val_unit, clkval =3D Val_unit;

=A0Begin_roots2(tmval, clkval);
=A0 =A0tm.tm_sec =3D Int_val(Field(t, 0));
=A0 =A0tm.tm_min =3D Int_val(Field(t, 1));
=A0 =A0tm.tm_hour =3D Int_val(Field(t, 2));
=A0 =A0tm.tm_mday =3D Int_val(Field(t, 3));
=A0 =A0tm.tm_mon =3D Int_val(Field(t, 4));
=A0 =A0tm.tm_year =3D Int_val(Field(t, 5));
=A0 =A0tm.tm_wday =3D Int_val(Field(t, 6));
=A0 =A0tm.tm_yday =3D Int_val(Field(t, 7));
=A0 =A0tm.tm_isdst =3D -1; /* tm.tm_isdst =3D Bool_val(Field(t, 8)); */ =A0 =A0clock =3D mktime(&tm);
=A0 =A0if (clock =3D=3D (time_t) -1) unix_error(ERANGE, "mktime"= , Nothing);
=A0 =A0tmval =3D alloc_tm(&tm);
=A0 =A0clkval =3D copy_double((double) clock);
=A0 =A0res =3D alloc_small(2, 0);
=A0 =A0Field(res, 0) =3D clkval;
=A0 =A0Field(res, 1) =3D tmval;
=A0End_roots ();
=A0return res;
}

The field tm.tm_isdst is not really a boolean from C's perspective. It = can be one of *three* states: positive for DST, zero for non-DST, and negat= ive to query the system timezone database for the value. It looks like at o= ne point Unix.mktime was written to take the value you gave it, but this wa= s commented out and the value was fixed to -1. This is why it uses the time= zone's daylight savings correction regardless of what you pass in.

Would it be possible to have a new function in the standard library with th= e commented-out behavior instead? As it stands now I don't see any reas= onable way to get a UTC float from a Unix.tm.

As far as XmlRpc-Light is concerned, I will probably rewrite this function = in terms of Netdate, since Ocamlnet is already one of my dependencies. Apol= ogies to anyone who is affected by this bug (hopefully, no one).

Thanks,
Dave


--0016364ecae01540ac048139e4c7--