You’d think that in 2010, date processing is something that is easily done in Java (and hence GWT), in a consistent cross-platform way. And you’d be wrong.

When I’m talking date processing, I mean simple calendar date (not time) operations, like: get today’s date, add a number of days, compute the number of days between two dates, etc. The original sin, so to speak, is that Java doesn’t have a class to represent a day; Java’s Date class is actually more like a timestamp: it encapsulates a moment in time (with a millisecond precision) stored as the number of milliseconds to/from the moment called “epoch”, which is arbitrarily fixed at January 1, 1970, 00:00:00 GMT.

The methods related to date components (day of month, month, year, etc.) have all been deprecated since the apparition of the Calendar class (JDK 1.1). The trouble is, Calendar isn’t available in GWT’s JRE emulation library. So what do most programmers do? They use the deprecated methods of class Date. For example to create a Date that corresponds to a given day, they would use new Date(y, m, d). Well it’s deprecated, but it works, right?

Wrong. When instantiating a Date object using these deprecated methods, each JavaScript implementation tries to do its best to guess the correct timestamp, based on things such as the current time zone and whether Daylight Savings Time was effective at that time, and of course these rules vary by OS, JavaScript implementation and depend on the client’s regional settings. I’m not going into details now, but the bottom line is: you can’t expect to get a consistent behaviour.

Actually, if you might not notice this problem if all you do is manipulate local dates that were created on the client-side; the problem really becomes a nightmare when you mix locally instanciated dates with serialized dates from the server.

We’ve spent an incredible amount of energy and time to work around this issue, which is made worse by GXT’s DateWrapper and DateTextField. The awkward but kind-of working solution that we use now is to subtract Date.getTimezoneOffset() from Date.getTime() in order to “cancel out” the client’s time zone and DST. Not pretty.

If I had to do my current project again, I would definitely stay away from the Date type on the client side. As primitive as it may sound, if I have to manipulate dates without a time part, I would stick to using a (day, month, year) triplet and do as little date calculations on the client-side as possible.

You’ve been warned!

21 comments on “GWT and JavaScript Date hell

  • Agree with you. I’ve had the same problems you mention above and it is hell. They expect you to use a deprecated java.util.Date with minimal utilitary methods to manipulate heavy date operations.

    Currently, I am working on a project where I need to perform the same date-related operations both in browser tier and business tier and the only solution until now has been to use this class. As you know, DateWrapper can only be used on the browser layer since it makes calls to javascript.

    Fortunately, this logic is highly isolated and we are expecting GWT creators and contributors to delivery a decent Calendar emulation.

    • We have the same need of doing similar date calculations both in the browser and on the business tier, and so we have 2 DateUtils classes with essentially the same methods: one for the browser that uses deprecated Date methods and other homebrew approximations, the other for the server that uses proper Calendar methods. Not pretty.

  • Did you look at Joda-Time ( ?

    It has been mentioned as a possible replacement of Java Date, I think it has been suggested actually for GAE as the new primary Date class.

    I just found out the Datanucleus now supports Joda-Time (datanucleus is used by the GAE datastore to access BigTable). Maybe it would make sense to for GWT and GAE to support Joda-Time as primary Data class ?

    • As we were hitting this Date nightmare, I came across Joda-time, which sounded like just what I was looking for… but the GWT port Goda-time looks stalled with a warning from 2008 on the front page “The release file has been deprecated until recently identified licensing issues are resolved”…

  • Only problem I’ve had so far with dates is passing just a date (without the time). GXT will default it to midnight, as will JDBC after you pull it out of the database. So if the client and server are not in the same timezone, there could be some date rolling forward or backward. I solved this by subclassing Date and having a custom encoder (currently through Errai, but it’s also possible in regular GWT). I just do it so that it’s encoded as a yyyy-MM-dd String and decode that on the client or server which makes it midnight in whichever timezone they’re in, thus making it not rollover when it’s passed.

    • That’s exactly why I recommend against using the Date type if you are just dealing with real dates (days) not timestamps. The whole Java Date/Calendar stuff is a mess, there should be a redesign like the collections package did to replace Vector & co. But i’m afraid Date has too mush legacy for this to happen :(

  • These date problems are why we interated the excellent datejs library ( to my latest GWT project. We added a few JSNI utility methods and now we have good date handling on every browser and in every locale. It’s made our lives much easier.

    • I didn’t know about this library, but it looks exactly like what we needed. Is your GWT wrapper open source or otherwise available?

  • Hi, I stumbled across this article because I was having the exact same problem.. the fact that GWT doesn’t have a proper solution for this is ridiculous, but I did try the datejs library and as far as I can tell it does work very well!
    As Zack said, just include the js file in your application and then use it via native JavaScript (JSNI) methods.
    Glad I found this post!

    • DateJs looks nice, but I’m not sure it solves the same problem.
      Let me know how it goes!

    • This is great! I haven’t tested it extensively but it looks good so far… I hope you don’t mind that I tweeted about it :)

      • Yeah, that’d be awesome. If you have any feedback feel free to contact me, my email address is on the project page.

  • Hi Olivier,
    I was wondering what was the operation you’ve made in order to sync Date instances generated in the client browser (in ant timezone) and the Dates on the server. Subtracting the Date.getTimezoneOffset by the Date.getTime can make things really messy (at least if you’re using GXTs DateField).

    Also, for presenting the Dates coming from the server I’m currently using the DateTimeFormat with a specific TimeZone created in the client side. Looks ok so far. Is that you’re approach as well?


    • Hi, actually subtracting Date.getTimezoneOffset() was the only reliable cross-platform way that we found. The trick is to set the server timezone to GMT with the appropriate java command line option that I don’t remember right now… For presenting the dates on the client we also use the same approach as you.

Leave a Reply

Your email address will not be published. Required fields are marked *