From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,e686c2c95beefb1c X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news1.google.com!news.glorb.com!news2.telebyte.nl!fu-berlin.de!uni-berlin.de!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Inserting Calendar.Time in a database Date: Fri, 6 Aug 2004 12:44:52 +0200 Message-ID: <94tir0ejn3n4$.a7o1lv87loha$.dlg@40tude.net> References: <1jgik0ntrex36$.1pyha1husddpe.dlg@40tude.net> <41134e18$1_1@baen1673807.greenlnk.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: news.uni-berlin.de XyebZ12iA0HKAj3/Y4ZnFgro7zoyyhtKuD8HTNdFrIJ6oVsRE= User-Agent: 40tude_Dialog/2.0.12.1 Xref: g2news1.google.com comp.lang.ada:2603 Date: 2004-08-06T12:44:52+02:00 List-Id: 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