«

I have two applications; one is a Java application that uses Joda, and
stores dates and times, with timezone info, in a database by storing
the number of milliseconds since the epoch, and a Joda timezone ID.
The other application is written in C++, and reads the timestamp and
timezone ID from the database. The C++ application needs to convert
the time to the timezone stored in the db.

I'm having trouble coming up with a good approach to take here. The
main issue is daylight savings time. It's fairly trivial for me to
write a Java program that builds a list of timezone ID's and their
associated GMT offsets, and using that list to give the C++
application the info it needs for the conversion, but I have not been
able to come up with a good way to support daylight savings time (and
also to support the dst-adjusted display names of timezones, e.g.
"EST" vs "EDT" for EST5EDT) in the C++ application short of
reimplementing all of the logic for every timezone ID by hand -- which
is less than ideal.

I realize this may be slightly off topic, but it is related to Joda.
Apologies if this is the wrong place to ask... but I have not been
able to come up with any solutions. Has anybody here ever done
anything like this, or does anybody have any ideas about a good way to
add Joda timezone ID support to non-Java applications? Ideally I'd
like to support most of the Joda timezone IDs (both generic IDs like
"EST5EDT" and city IDs like "America/New_York"), but I would be
willing to limit the Java application to a representative subset of
the IDs if that makes it easier to deal with on the C++ side of
things. Any suggestions would be greatly appreciated.

Thanks a lot!
Jason

jasonc wrote:
> I'm having trouble coming up with a good approach to take here. The
> main issue is daylight savings time. It's fairly trivial for me to
> write a Java program that builds a list of timezone ID's and their
> associated GMT offsets, and using that list to give the C++

Especially if you use
<http://java.sun.com/javase/6/docs/api/java/util/TimeZone.html>

> application the info it needs for the conversion, but I have not been
> able to come up with a good way to support daylight savings time (and
> also to support the dst-adjusted display names of timezones, e.g.
> "EST" vs "EDT" for EST5EDT) in the C++ application short of

"EST" can be UTC+11, UTC+10 or UTC-5.
"EDT" can be UTC+11 or UTC-4.
Other such ambiguities abound.
<http://www.timeanddate.com/library/abbreviations/timezones/>

> reimplementing all of the logic for every timezone ID by hand -- which
> is less than ideal.

Why does the C++ have to handle this? Why not let the Java do it?

Between Calendar, TimeZone and the upcoming JSR 310 stuff
<http://today.java.net/pub/a/today/2008/09/18/jsr-310-new-java-date-time-api.html>
Java is in the best position to handle it.

--
Lew

On Mar 2, 9:19 pm, Lew <no...@lewscanon.com> wrote:
....
> Between Calendar, TimeZone and the upcoming JSR 310 stuff
> <http://today.java.net/pub/a/today/2008/09/18/jsr-310-new-java-date-ti...>
> Java is in the best position to handle it.

Today Java's Calendar and TimeZone are a piece of crap
compared to JODA time. JSR 310 ain't out yet and...

The OP is already using the most powerful and most elegant
solution out there, JODA time.

That very link you gave for JSR-310 gives credit where it's
due, that is to Joda time (basically JSR-310 is Joda time).

You didn't answer at all the OP's question.

On Mar 2, 4:19*pm, Lew <no...@lewscanon.com> wrote:
> jasonc wrote:
> > I'm having trouble coming up with a good approach to take here. The
> > main issue is daylight savings time. It's fairly trivial for me to
> > write a Java program that builds a list of timezone ID's and their
> > associated GMT offsets, and using that list to give the C++
>
> Especially if you use
> <http://java.sun.com/javase/6/docs/api/java/util/TimeZone.html>
>
> > application the info it needs for the conversion, but I have not been
> > able to come up with a good way to support daylight savings time (and
> > also to support the dst-adjusted display names of timezones, e.g.
> > "EST" vs "EDT" for EST5EDT) in the C++ application short of
>
> "EST" can be UTC+11, UTC+10 or UTC-5.
> "EDT" can be UTC+11 or UTC-4.
> Other such ambiguities abound.
> <http://www.timeanddate.com/library/abbreviations/timezones/>
>
> > reimplementing all of the logic for every timezone ID by hand -- which
> > is less than ideal.
>
> Why does the C++ have to handle this? *Why not let the Java do it?

Well, they're two separate applications in a large business system; I
can't combine them like that, unfortunately. Also, I'm actually only
storing the hour and minute, not a date, it's sort of a strange
situation that doesn't need to be explained here but the Java side
doesn't have quite enough info to convert the time into a known
timezone that the C++ app can assume.

> Between Calendar, TimeZone and the upcoming JSR 310 stuff
> <http://today.java.net/pub/a/today/2008/09/18/jsr-310-new-java-date-ti...>
> Java is in the best position to handle it.


I figured it out, though. Or rather, got some good info from the Joda
mailing list. Joda (and I think Java's implementation as well) uses
the tz database here for all the timezone IDs:

http://www.twinsun.com/tz/tz-link.htm

As it turns out, there's both a GNU C implementation, and for C++,
boost provides a date/time library with time zone support based off
the same database:

http://www.boost.org/doc/libs/1_38_0...me.tz_database

Pretty handy! So I can share the timezone IDs between the two, and
both have date/time packages that can deal with the same set of
timezones (Joda and boost). So this is the solution; thought I'd post
it here in case anybody found this thread some day.

Thanks for your replies,
Jason

wrote:
> On Mar 2, 9:19 pm, Lew <no...@lewscanon.com> wrote:
> ...
>> Between Calendar, TimeZone and the upcoming JSR 310 stuff
>> <http://today.java.net/pub/a/today/2008/09/18/jsr-310-new-java-date-ti...>
>> Java is in the best position to handle it.
>
> Today Java's Calendar and TimeZone are a piece of crap
> compared to JODA time. JSR 310 ain't out yet and...
>
> The OP is already using the most powerful and most elegant
> solution out there, JODA time.
>
> That very link you gave for JSR-310 gives credit where it's
> due, that is to Joda time (basically JSR-310 is Joda time).

JODA seems very popular.

But I prefer ICU4J.

Arne

jasonc wrote:
> I have two applications; one is a Java application that uses Joda, and
> stores dates and times, with timezone info, in a database by storing
> the number of milliseconds since the epoch, and a Joda timezone ID.
> The other application is written in C++, and reads the timestamp and
> timezone ID from the database. The C++ application needs to convert
> the time to the timezone stored in the db.
>
> I'm having trouble coming up with a good approach to take here. The
> main issue is daylight savings time. It's fairly trivial for me to
> write a Java program that builds a list of timezone ID's and their
> associated GMT offsets, and using that list to give the C++
> application the info it needs for the conversion, but I have not been
> able to come up with a good way to support daylight savings time (and
> also to support the dst-adjusted display names of timezones, e.g.
> "EST" vs "EDT" for EST5EDT) in the C++ application short of
> reimplementing all of the logic for every timezone ID by hand -- which
> is less than ideal.
>
> I realize this may be slightly off topic, but it is related to Joda.
> Apologies if this is the wrong place to ask... but I have not been
> able to come up with any solutions. Has anybody here ever done
> anything like this, or does anybody have any ideas about a good way to
> add Joda timezone ID support to non-Java applications? Ideally I'd
> like to support most of the Joda timezone IDs (both generic IDs like
> "EST5EDT" and city IDs like "America/New_York"), but I would be
> willing to limit the Java application to a representative subset of
> the IDs if that makes it easier to deal with on the C++ side of
> things. Any suggestions would be greatly appreciated.

Standard C++ does not have timezone support.

But get the boost library - it has timezone support.

Arne