Using the same program in the playground gives me the following output in Firefox 3.6.3, Chrome 5, Safari 4.0.5 and IE 8 (OS is Windows Vista):
005423 playground.Application[436]: Mon, 31 Mar 1980 22:00:00 GMT 005430 playground.Application[436]: Wed, 30 Apr 1980 22:00:00 GMT 005447 playground.Application[436]: Wed, 31 Mar 2010 22:00:00 GMT 005453 playground.Application[436]: Fri, 30 Apr 2010 22:00:00 GMT In my timezone the offset is 1 hour and 2 hours during daylight saving time. As you can see the first line shows the wrong time, it should be 23:00:00. Qooxdoo RPC sends normalized (UTC) dates to the backend. The "problem" is that in the backend a Java date object is created in my timezone with the value 03/31/1980 23:00:00 because Java knows that, at that time only was a offset of one hour. It isn't a problem of sending the data in the wrong format, it's a problem of Javascript (maybe only on some systems). If I send the Java Date object back to the frontend, I get the correct date back (of course, it is again wrong transferred from UTC to local time). But my backend stores everything inside a database and other applications (for example data exports to xls, csv or pdf) using the data from the database. So this apps get wrong data. Regards, Andreas Von: Derrell Lipman [mailto:[email protected]] Gesendet: Samstag, 12. Juni 2010 16:53 An: qooxdoo Development Betreff: Re: [qooxdoo-devel] Java backend and Javascript date On Sat, Jun 12, 2010 at 07:37, Fink, Andreas <[email protected]> wrote: Hi Derrell, I'm using Firefox Version 3.6.3 My idea for a workaround is that the RpcJava backend can take care of the problem while serialization and de-serialization the date objects. I'll have a look at it, maybe I'm able to provide such a workaround. The proper way to deal with this is to NEVER send dates that are not normalized between computers. If you always send UTC timestamps, there is no daylight savings time conversion to worry about. Regarding Firefox, I tried running the following program in the playground: var d = new Date("4/1/1980"); this.warn(d.toUTCString()); d = new Date("5/1/1980"); this.warn(d.toUTCString()); d = new Date("4/1/2010"); this.warn(d.toUTCString()); d = new Date("5/1/2010"); this.warn(d.toUTCString()); The results are as follows: 496761 playground.Application[440]: Tue, 01 Apr 1980 05:00:00 GMT 496769 playground.Application[440]: Thu, 01 May 1980 04:00:00 GMT 496773 playground.Application[440]: Thu, 01 Apr 2010 04:00:00 GMT 496777 playground.Application[440]: Sat, 01 May 2010 04:00:00 GMT In my timezone, during daylight savings time, the offset is 4 hours, and it is 5 hours the rest of the year. This is showing that my Firefox 3.5.7 on Linux knows that daylight savings time isn't yet in effect on 1 April 1980, but is in effect on 1 May of that year. In 2010, after the rules changed, both 1 April and 1 May are during daylight savings time. I highly suspect that JavaScript is using the native date/time functions of the operating system on which it is running. It may well be that Firefox 3.5.7 provides the incorrect dates if it's running on an old Windows system (or a not up-to-date Linux system). In any case, always send UTC dates over the wire, and you'll never have a conversion problem. Cheers, Derrell ------------------------------------------------------------------------------ ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
