Hi, Is it not possible when the client requests to print a document to make the client timezone part of the request? In that case you can server side very easily convert from the stored TZ to the client TZ before printing...
You should simply be able to ask the client what it's timezone is. In pure Javascript it would be: var offset = new Date().getTimezoneOffset(); which will return you the amount of minutes you are offset so a UTC+2 would return 120 where UTC-10 would result in -600 etc... You could even allow your client to override their system TZ and print the document as if it where printed in a TZ of their choice. Regards, Rob On Wed, Aug 1, 2012 at 5:12 PM, Jens <jens.nehlme...@gmail.com> wrote: > Hi, > > how do you work with dates/timezones in your apps? I have the following > situation: > > (Client browser, app server, database server live in Germany and we have > UTC+1 or UTC+2 when daylight saving time is active) > > A user chooses a Date + Time (e.g. from GWT's DateBox) and we send that > date object to the server and store it in database. On the client side > everything is visually consistent until we want to print something. The > report is generated on the server and the date that the user has entered * > can* be off by 1 hour on the server which results in wrong dates in the > report compared to the information visible inside the client app. Also if > you use DateBox and only display the day portion of a date the date will > still be off by one hour but to the user it is visible as being off by one > day in the report because the date contains 00:00:00 as time portion which > will become 23:00:00 for the previous day on the server. > > As an example the user may chooses 26.10.1951 12:00:00 via the GWT > DateBox. Chrome, Safari, IE and Opera think (java.util.Date delegates to > JsDate class in compiled app) that daylight saving time is active for that > date (UTC+2 and thus date.getTimezoneOffset() returns -120 minutes). > Unfortunately we don't have daylight saving time from 1950 to 1979 at all > in Germany and our app server (= JVM) / database server knows this fact > which results in a differently rendered date on the server. So if we render > that date on the server its off by one hour (UTC+2 on client vs. UTC+1 on > server). Firefox does correctly treat the date as UTC+1. On the other hand > there are other dates where Firefox fails but other browsers do it > correctly. > > As the GWT DateBox uses a DefaultFormat that uses DateTimeFormat and calls > dtf.format(date) without a timezone I provided a custom Formatter that > explicitly uses GWT's europeBerlin timezone. Now the GWT DateBox shows > 26.10.1951 11:00:00 because GWT's timezone provided to the DateTimeFormat > detects that no day light saving time is active at this date. Now client > and server render the date the same although the browser created it > incorrectly with UTC+2. BUT sadly there are other dates where GWT's > timezone information also failes and differs from the server timezone > information. > > So short story: Its currently impossible to create a consistent behavior > between client and server for certain dates. It seems like that GWT's > timezone info and the browsers native timezone infos have different data > than the tz database used by Unix / Linux / Java / database server. There > are also differences between browsers itself. > > So how do you guy work with dates in your app? I mean as an example it can > be as easy as selecting a birthday (without time => 00:00:00) and use that > birthday on server side in a report. Now you are maybe a day older in the > report if you live in germany :-) > > The only "partial" solution we can think of is to always use 12:00:00 as > time if you are only interested in the day portion of date (to avoid off by > one day problem) and to use a fixed non DST day (maybe 01.01.1970) which is > safe in all browsers if you are only interested in the time portion of date > (to make sure its rendered the same on client/server). Obviously this also > means that we can never store day and time in a single date instance. > > So whats your experience with timezones and/or do you have other possible > solutions? Or have you never noticed this discrepancy in your timezone? In > Dev mode everything works fine, because its Java like on the app server. > > -- J. > > -- > You received this message because you are subscribed to the Google Groups > "Google Web Toolkit" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/google-web-toolkit/-/q04nxG_F8BkJ. > To post to this group, send email to google-web-toolkit@googlegroups.com. > To unsubscribe from this group, send email to > google-web-toolkit+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/google-web-toolkit?hl=en. > -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
