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=-0.4 required=5.0 tests=AC_FROM_MANY_DOTS,BAYES_00
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Thread: 103376,27d478aa577d0f8b
X-Google-Attributes: gid103376,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news2.google.com!news2.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!t-online.de!news-lei1.dfn.de!news1.uni-leipzig.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: Wilhelm Spickermann <praxto.20.unbenutzbar@spamgourmet.com>
Newsgroups: comp.lang.ada
Subject: Re: Getting current date and time
Date: Sat, 28 Jul 2007 10:20:13 +0200
Message-ID: <5h0chuF3htvsqU1@mid.individual.net>
References: <1185139279.071088.106330@d55g2000hsg.googlegroups.com>
 <1185145228.126307.301840@d55g2000hsg.googlegroups.com>
 <1185220676.926492.258330@g4g2000hsf.googlegroups.com>
 <1185220926.372760.52420@q75g2000hsh.googlegroups.com>
 <1185221307.073177.279370@n60g2000hse.googlegroups.com>
 <1185227010.432172.50300@e16g2000pri.googlegroups.com>
 <1185267194.506294.197760@w3g2000hsg.googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7Bit
X-Trace: individual.net /XX7iI/m2OTrcw6BlmSfpQt8iLhV+l6OvnUD3TD2kO2G1Nkptu
Cancel-Lock: sha1:SL4I2D7UO6PHBkGye8WbhcHLbHg=
Xref: g2news2.google.com comp.lang.ada:1232
Date: 2007-07-28T10:20:13+02:00
List-Id: <comp.lang.ada>

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