comp.lang.ada
 help / color / mirror / Atom feed
From: Wilhelm Spickermann <praxto.20.unbenutzbar@spamgourmet.com>
Subject: Re: Getting current date and time
Date: Sat, 28 Jul 2007 10:20:13 +0200
Date: 2007-07-28T10:20:13+02:00	[thread overview]
Message-ID: <5h0chuF3htvsqU1@mid.individual.net> (raw)
In-Reply-To: 1185267194.506294.197760@w3g2000hsg.googlegroups.com

Maciej Sobczak wrote:

>> In Ada 2005, this is handled by the Differences procedure in
>> Ada.Calendar.Arithmetic (9.6.1).  You can use
>> Ada.Calendar.Time_Of to create the Time value for January 1,
>> 1970, and then use that as a parameter to Differences.
> 
> The problem is that I need just a number of seconds (this is
> for interfacing with other software which uses that Unix-like
> time descriptions), so I cannot use the value which is broken
> down into several components.
> 

Then the situation contains even more problems. Every Unix time_t
value has two different meanings depending on the currently(!)
used configuration of the machine. If the local time
configuration (/etc/localtime) is taken from one of the "real"
TZ-Files, then a time_t value of 946684900 decribes the time
"1-jan-2000 00:01:18 UTC". But if the system is configured to
use "posix" TZ-Files, then the same timestamp describes
"1-jan-2000 00:01:40 UTC". 

So if you want to produce unix compatible time stamps, you will
have to know the configuration of the destination machine at the
time when the time_t value will be processed. 

If you want to interpret time stamps, you need to know the
configuration of the creating machine at the time this time
stamp was made. 

If the configuration is one of the "posix" ones, then it's
impossible to create time stamps representing times during
positive leap seconds. Conversely its possible to create time
stamps for times during negative leap seconds leaving us with
time stamps corresponding to no point in real time. Good thing,
that there were no negative leap seconds yet...

If the configuration is one of the "real" ones, then you cannot
compute date strings for time_t values in the far future (more
than about half a year), as the result depends on decisions not
made yet (leap second insertion).

Yet another problem: For historical data the TZ-Files cannot be
taken for real without checking. As TZ-Files fail to have any
representation for "we don't know" or "well, it depends on ...",
many known problems had to be ignored when creating the
TZ-Files. The comments in the source files of the ZIC (Zone
Information Compiler; ZIC produces TZ-Files) should be consulted
if necessary. 

Wilhelm Spickermann




  parent reply	other threads:[~2007-07-28  8:20 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-22 21:21 Getting current date and time Maciej Sobczak
2007-07-22 23:00 ` Martin
2007-07-23 15:24   ` koburtch
2007-07-23 19:57   ` Maciej Sobczak
2007-07-23 20:02     ` Maciej Sobczak
2007-07-23 20:08       ` Maciej Sobczak
2007-07-23 21:43         ` Adam Beneschan
2007-07-24  8:53           ` Maciej Sobczak
2007-07-24  9:41             ` Georg Bauhaus
2007-07-24  9:58               ` Maciej Sobczak
2007-07-24 15:24             ` Adam Beneschan
2007-07-25  7:26               ` Maciej Sobczak
2007-07-25  7:42                 ` AW: " Grein, Christoph (Fa. ESG)
2007-07-28  8:20             ` Wilhelm Spickermann [this message]
2007-08-01  9:45         ` Jacob Sparre Andersen
2007-07-23 21:39       ` Adam Beneschan
2007-07-23 19:26 ` Gautier
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox