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
