Re: Inserting Calendar.Time in a database

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

On Fri, 6 Aug 2004 10:28:58 +0100, Martin Dowie wrote:

> Dmitry A. Kazakov wrote:
>>> Ada.Calendar.Time_Zones might be of use to you. You could store
>>> the value as a string (Ada.Calendar.Formatting).
>>>
>>> See http://www.martin.dowie.btinternet.co.uk/
>>
>> I see a problem with it. UTC_Time_Offset is not constant, so there
>> also should be an atomic way to get exact UTC.
> 
> Sorry, not sure what you're getting at here. The UTC_Time_Offset will change
> due to daylight saving, so it can never be a constant.
> 
> For Windows, I can't find anything that states if "GetTimeZoneInformation"
> is atomic or not and this is the routine that returns the time structure.

Under Windows I never would use it to get UTC. I would call
QueryPerformanceCounter. Then to convert it to UTC I would use:

[periodically + statistical refinement]
   QueryPerformanceCounter 1
   GetSystemTimeAsFileTime
   QueryPerformanceCounter 2

Mean of 1+2 allows to calculate the offset to UTC epoch. The problem with
using GetSystemTimeAsFileTime alone is that it has a very low resolution,
so one should use some kind of statistical refinement to get closer to
QueryPerformanceCounter accuracy.

> But even if it isn't atomic it's only going to be 'wrong' at most twice a
> year and only for a second or so each time.

Should we shut down the systems for that period of time? (:-)) Then one
cannot deal with past and future times. The time zone itself is not
constant. Governments are very inventive in making our life harder. Time
stamps should be independent on this chaos.

So I am not convinced that Ada.Calendar is a proper place for dealing with
UTC. Time zones are OK there, no question. But similarity between zone
times and UTC is rather apparent. As I said UTC is monotonic, so it should
be Ada.Real_Time.

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