Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
Ocaml can't convert a GMT time into a float!
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Luca de Alfaro <luca@d...>
Subject: Re: [Caml-list] Ocaml can't convert a GMT time into a float!
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:

If you want to know why this bug drove me crazy for a couple of evenings,
you can read this blog

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,


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
> 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