Supporting Joda timezones in non-Java applications.

Discussion in 'Java' started by jasonc, Mar 2, 2009.

  1. jasonc

    jasonc Guest

    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, Mar 2, 2009
    #1
    1. Advertising

  2. jasonc

    Lew Guest

    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
    Lew, Mar 2, 2009
    #2
    1. Advertising

  3. jasonc

    Guest

    On Mar 2, 9:19 pm, Lew <> 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.
    , Mar 3, 2009
    #3
  4. jasonc

    jasonc Guest

    On Mar 2, 4:19 pm, Lew <> 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_...al_time.html#date_time.local_time.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
    jasonc, Mar 3, 2009
    #4
  5. jasonc

    Arne Vajhøj Guest

    wrote:
    > On Mar 2, 9:19 pm, Lew <> 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
    Arne Vajhøj, Mar 3, 2009
    #5
  6. jasonc

    Arne Vajhøj Guest

    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
    Arne Vajhøj, Mar 3, 2009
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. John Giblin

    Timezones for asp.net

    John Giblin, Nov 4, 2003, in forum: ASP .Net
    Replies:
    0
    Views:
    1,813
    John Giblin
    Nov 4, 2003
  2. Wolfgang
    Replies:
    5
    Views:
    1,474
    Tris Orendorff
    Feb 19, 2004
  3. =?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=

    PEP 3131: Supporting Non-ASCII Identifiers

    =?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=, May 13, 2007, in forum: Python
    Replies:
    399
    Views:
    4,576
  4. Michael Yanowitz

    RE: PEP 3131: Supporting Non-ASCII Identifiers

    Michael Yanowitz, May 14, 2007, in forum: Python
    Replies:
    4
    Views:
    272
    Chuck Rhode
    May 15, 2007
  5. loial
    Replies:
    25
    Views:
    2,545
Loading...

Share This Page