Wow, that's what I call real help, thank you!! I had an error in reasoning, so the problem is solved.
Regards, Markus Andreas Junghans wrote: > > Hi Markus, > > Am 10.02.2007 um 16:04 schrieb Markus Bäurle: > >> I have the following problem: >> The user can enter a date, this date is transferred to the server >> (Tomcat), >> and a scheduler task on the server starts an arbitrary action >> >> The problem is that the UTC timezone is used. When I enter, for >> example, the >> 01.07.2007 12:00 on the java side this is interpreted as 01.07.2007 >> 11:00, >> so there is one hour difference and the task is started one hour to >> early. >> >> I found out that the automatic change from summertime to wintertime >> is the >> cause: >> If the checkbox "Uhr automatisch auf Sommer-/Winterzeit umstellen" (in >> Windows XP German) in System-Date/Time dialog is checked, the problem >> exists, if this checkbox is not checked, everything is fine >> (Browser has to >> be restarted after check/uncheck the checkbox) > > To the contrary - in my tests, things work if the checkbox _is_ > checked. Let me explain: The moment in time we're talking about (July > 1st 2007, 11:00, Central European Summer Time) is equal to > 1183280400000 milliseconds since January 1st 1970, 0:00 UTC. > > If the automatic DST checkbox is checked, the result of (new Date > (2007, 6, 1, 11)).getTime() on a German Windows XP in the CE(S)T > timezone is exactly 1183280400000. This is correct, since getTime() > is defined as returning the milliseconds since January 1st 1970, 0:00 > UTC. > > If the checkbox is _not_ checked, the result of (new Date(2007, 6, 1, > 11)).getTime() is 1183284000000. This is wrong for the timezone we > have in Germany (CE(S)T). It would be correct for pure CET (i.e. a > central European timezone where there's no summer time). > >> new Date().getTimezoneOffset() returns -60 >> new Date((Date.UTC(2007, 6, 1, 11, 0, 0, 0)).getTimezoneOffset() >> returns >> -120 > > This is exactly what's expected. JavaScript doesn't differentiate > between a timezone offset and an additional DST offset. For further > explanation see http://developer.mozilla.org/en/docs/ > Core_JavaScript_1.5_Reference:Global_Objects:Date:getTimezoneOffset > >> On the Java side the timezone offset is always -60. > > Yes and no. In Java, there are several methods to determine the offset: > > java.util.TimeZone.getOffset: returns the offset _including_ DST offset > java.util.TimeZone.getRawOffset: returns the offset _excluding_ DST > offset > java.util.TimeZone.getDSTSavings: returns _only_ the DST offset (0 or > 1 hour) > > And there are two fields for time zone offsets in java.util.Calendar > (which you have to add to get the actual offset): > > java.util.Calendar.ZONE_OFFSET: the time zone offset (excluding DST) > java.util.Calendar.DST_OFFSET: the DST offset > > Please _don't_ use the deprecated java.util.Date.getTimezoneOffset. > >> I cannot ensure that all users have this checkbox unchecked so what >> is the >> best solution to prevent this problem? > > Again, you should make sure that the checkbox is _checked_ (which is > the default). If a user unchecks this box, Windows XP interprets it > as "this user tells me he or she lives in a CET timezone without > summer time", and this confuses time calculations (since the user > actually lives in a timezone _with_ summer time). Or you could see it > this way: If the users unchecks this box and then enters a date in > July, Windows/the browser can't know that the user will change the > time in March manually. > > Anyway, I think your real problem is that your server application (or > a library you use) doesn't correctly deal with dates. Let's assume > the following workflow (and also that the automatic DST checkbox is > checked): > > - The user enters a date (e.g. in year, month, day, hour, minute > fields) in local time. > > - To get a JavaScript Date object, you should use the usual Date > constructor: new Date(year, month-1, day, hour, minute). The Date > constructor works with local time. DO NOT use Date.UTC (unless you > want your users to think in UTC)! > > - Use an RPC mechanism to transfer the date to the server. Whether > you're using JSON-RPC-Java or the qooxdoo RPC (which is not clear > from your eMail), the result should be the same: The date is > transferred in UTC (either in milliseconds or as UTC date > components), and a correct Date object is constructed on the Java side. > >> I don't want to convert between Date and String. > > With the workflow above, you should get a correct java.util.Date > object representing the time entered by the user. Please note that > java.util.Date _does not_ have any time zone information! In fact, if > you don't use its deprecated methods, it's more or less a wrapper > around the number of milliseconds since January 1, 1970 GMT (where > GMT == UTC for all practical purposes). > > If you want to validate whether you received the correct date, > _don't_ use deprecated methods like java.util.Date.getHours! Instead, > print the date using a java.text.SimpleDateFormat instance (which by > default works in the local timezone where the JVM is running). > > > To summarize: I think you have a problem in your server-side code. > Maybe you perform some calculations with the timezone offset (but > disregarding the DST offset)? It would be best if you could provide > some details about your server-side date handling. > > Regarding the automatic DST checkbox in Windows: If a user really has > this box unchecked, he or she (unintentionally) lies about the local > time zone. Maybe what you _really_ want is that the user should enter > a local date (but local relative to the server, not to the client). > If this is the case, you should transfer the user entries as strings, > not as dates, and let the server perform the conversion. > Alternatively, you can send the Date and its timezone offset (via > getTimezoneOffset) to the server so that it can re-calculate the > actual values entered by the user. But such an approach breaks as > soon as you have international users in multiple time zones. > > Regards, > > Andreas > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job > easier. > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > qooxdoo-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel > > -- View this message in context: http://www.nabble.com/JSON-RPC-and-Date-Timezone-Problem-tf3205557.html#a8910668 Sent from the qooxdoo-devel mailing list archive at Nabble.com. ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
