Converting datetimes from/to UTC/GMT including daylight saving

[Michael Pfeifer]

Hi all,

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.
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. I need to handle birthday dates also.
I tried to integrate Boost libraries (see www.boost.org), but I was
not able to get them running together with SGI STL and also got
internal compiler errors when compiling them with MS VC++ 6 SP5.
So should you have any suggestions, they would be HIGHLY appreciated.
Thanx in advance.

Regards,
Michael

 

[Randy Howard]

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.

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?

I need to handle birthday dates also.

Well, if you need a bigger date format, something like ISO 8601
might be handy (google should tell you more than enough). It
incudes the century in the date format, so you should be able
to represent any date AD, surely you aren't worrying about
birthdays of anyone before then?

The "calendar FAQ" (again google) might be very helpful to you
as well.

Or roll your own "big date" format and what not.

 

[Dave Thompson]

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.

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 don't understand how a birthday date is different from any other.

- David.Thompson1 at worldnet.att.net

 

[Michael Pfeifer]

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.

Exactly that is problem

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".)

thanx, but I see clever guys like you get it anyway ))

<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 don't understand how a birthday date is different from any other.

Well, I said that to emphasize that dates are most likely to be before
(note, I did not say "older" ) 01.01.1970 and that I can not live
with that restriction

 

[red floyd]

Exactly that is problem

In addition, the time routines are not symmetric. To wit, there's

localtime() and gmtime(), which will take a time_t* and return a struct tm
with either the local or UTC time respectively. However, there is only one inverse
function: mktime(), which takes a struct tm with the localtime and returns a time_t.
There is no mkgmtime(), which would be the inverse of gmtime.

I have a similar problem to the OP, and currently have a kluged workaround, but it breaks on DST transitions.
Any suggestions would be very appreciated!