Re: ctime library - is there anything better in c++?
On Nov 24, 11:56 am, Lars Uffmann <a...@nurfuerspam.de> wrote:
James Kanze wrote:
day of year (tm_yday) as well as the year (ok, actually
that is being counted from 1970
In time_t. In tm, its from 1900.
Ouch! So that is where that inconsistency comes from. I've
been wondrin why in my conversion routine, the date would
sometimes be 1970-01-01 when I try to convert a date lower
than the minimum tm value to a time_t. By the way, the
minimum for tm seems to be 1902-01-01 - though I'd have to do
some debugging on my code to be sure the observed behaviour of
my mini-program is indeed the behaviour of the underlying
conversion functions of ctime.
On most systems (or at least most Unix systems) today, time_t is
a 32 bit signed integer, measuring seconds from midnight, Jan.
1, 1970. If you do a little arithmetic, you'll find that this
allows you to represent from 1902 to 2038, roughly. Which
establishes the bounds for all of the time functions is
libraries which use this representation. After all of the noise
about the Y2K problem, implementations have gradually been
moving to 64 bits, but it doesn't happen overnight. (We've got
a lot of code which stores time_t on files. Luckily, we adopted
a text format.)
with time_t being a 32 bit integer). And again: this format
was designed mainly for file timestamps; the inventors
weren't worried about files which were modified before 1970,
since they couldn't exist.
Oh - okay, that makes a little more sense. I thought it was
meant for calendar calculations and the likes...
It wasn't designed intentionally to prevent them, but the
most important issue was file timestamps and such. Beyond that,
I imagine that they looked at what they were doing at the time:
it works very well for scheduling cron jobs and at requests, for
example, or measuring elapsed program runtime. I'm fairly
certain, however, that no consideration was given to the
possibility of using for historical dates, and maybe not really
too much, if any, to various bookkeeping uses (which can be
complicated by the fact that for the purposes of calculating
interest, a month is 1/12 of a year, regardless, and a day is
1/30 of a month, and nothing under a day counts).
For a general purpose library, 32 bits aren't enough, even
for a resolution of seconds. (A 64 bit value representing
nanoseconds is good for over 200,000 years, and representing
microseconds, for well over the expected age of the
universe. Which should cover most needs.)
I'm not so sure... What about the next universe? And the one
after that? Suppose I want to write a letter to my 10^913th
generation son? :D
Design a machine, or a data support, that will last that long,
and we'll talk about it:-).
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34