Re: Dates and Times in GNAT on Linux

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Sun, 13 Sep 2009 10:36:58 -0500, Marc A. Criley wrote:

> I'm confused about GNAT's implementation of some aspects of date/time 
> processing on Linux. I'm running GNAT GPL 2009 on Ubuntu Linux; I also 
> live in the US Central Time Zone and Daylight Savings Time is in effect 
> as I write this.
> 
> This is probably a stupid misunderstanding or mistaken expectations or 
> feature misuse on my part, but I would really like to know what's going on.
> 
> Basically what I'm trying to do is take the time I got from from 
> Ada.Real.Clock and convert it to a date/time rep.  The result I'm coming 
> up with is always an hour off. (DST effect? Read on...) Code will follow 
> in a bit.
> 
> I discovered that GNAT's implementation of Ada.Real_Time.Clock returns 
> the number of seconds since the UTC epoch start, which is very nice and 
> very handy.  Using Real_Time.Split I can get that number of seconds into 
> a visible type, Seconds_Count.
> 
> I can then get the start of the Unix/UTC epoch via:
>     UTC_Epoch_Start := Calendar.Time_Of(1970, 1, 1)
>                          + Duration(Calendar.Time_Zones.UTC_Offset * 60);
>     -- For where I live, right now the UTC_Offset is -300 minutes,
>     -- i.e. -5 hours.
> 
> Adding the Real_Time seconds count (as a Duration) to UTC_Epoch_Start 
> gives a Calendar.Time value containing the current UTC time, from which 
> I can generate an image...which is an hour off from the correct value.
> 
> So I'm thinking it might be a DST problem, but shouldn't the affected 
> Calendar procedures be taking that into account?

Hmm, it seems otherwise. It is DST now, and no DST for the time point you
calculated the epoch. So the epoch time is incoherent to the time now. Your
calculation presumes that (T + D1) + D2 = T + (D1 + D2) holds for any T, a
political time and any D1, D2, durations. That is wrong for political time.
(Ada.Calendar arithmetic is broken, when Ada.Calendar.Time is political
time) The problem is that UTC_Offset is not a constant, but itself is a
function of UTC time.

> Maybe my conversion from Real_Time.Time to Calendar.Time is flawed...I 
> don't know.  Any explanation or clarifications would be much appreciated.

You have to sum all clock skews (forth and back) within the interval
between the epoch and the time being converted. These skews will sum up to
either 0 or 1 hour, or maybe 1 hour + possibly n leap seconds. Not an easy
task.

P.S. I wished Ada.Calendar.Time_Zones weren't broken. This was discussed in
c.l.a. a couple of months ago.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de