By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
445,819 Members | 1,173 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 445,819 IT Pros & Developers. It's quick & easy.

Converting datetimes from/to UTC/GMT including daylight saving

P: n/a
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
Nov 14 '05 #1
Share this Question
Share on Google+
4 Replies


P: n/a
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.
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.
--
Randy Howard _o
2reply remove FOOBAR \<,
______________________()/ ()______________________________________________
SCO Spam-magnet: po********@sco.com
Nov 14 '05 #2

P: n/a
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
Nov 14 '05 #3

P: n/a
Dave Thompson <da*************@worldnet.att.net> wrote in message news:<e6********************************@4ax.com>. ..
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.

Exactly that is problem
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".)

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 need to handle birthday dates also.


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
Nov 14 '05 #4

P: n/a
Michael Pfeifer wrote:
Dave Thompson <da*************@worldnet.att.net> wrote in message news:<e6********************************@4ax.com>. ..
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.


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!

Nov 14 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.