On Tue, 9 Dec 2003 11:46:12 -0600, Randy Howard
<ra**********@FOOmegapathdslBAR.net> wrote:
In article <91**************************@posting.google.com >,
mu*******@web.de says... I need to convert datetimes from any timezone to UTC and back
considering daylight saving. It is not enough, to just add or subtract
the timezone offset.
Worst case, build a table of timezones and which of them use DST and
which do not, along with their normal offsets from UTC and do it
yourself.
Depending on how complete you want to be internationally and/or
historically, just "yes or no" for DST is not enough. There are dozens
if not hundreds of algorithms that are or have been used for DST plus
lots of instances that didn't obey any algorithm.
Also, I can not use c functions and structures like localtime and
time_h, since they only can handle datetimes "younger" than
01/01/1970.
ITYM "can't handle" typically?
ITHM *can* handle *younger* and *can't* handle *older*. (Aside: in
English we usually don't describe inanimate things, or concepts, as
"young"; "newer" or "more recent" would be better, or just "after".)
<Obtopic>The C and C++ standards do not require this limitation to the
Unix epoch, although it is practically universal.</> Of course that
doesn't help you much if you want to run on existing systems.
The Olson timezone code and database (including DST) is available from
ftp://elsie.nci.nih.gov/pub . It shouldn't be hard to change it to an
earlier epoch and larger range, using (C99) long long or equivalent,
common if not completely standard double, or just multiword arithmetic
(especially in C++ overloading normal arithmetic), although I'm not
aware of anyone having done so already. On most systems you could even
keep the nominally-same-as-standard-C API and leave your calling code
unchanged, although technically this (defining stdlib functions
yourself) is illegal; or you could change the names, e.g. my_mktime,
and the calls to them accordingly.
I need to handle birthday dates also.
I don't understand how a birthday date is different from any other.
- David.Thompson1 at worldnet.att.net