Nico Klasens <[EMAIL PROTECTED]> wrote: > You are right! The editwizards have a problem with editing the date and time > when the client is not in the same timezone as the server. That could also > explain the issue Michiel noticed, some time ago, that his linux and windows > machine had a one hour time difference. > The javascript code uses the Date object to get the numbers in the dropdown > boxes. The Date object calculates the numbers based on the Timezone of the > client machine. I hadn't looked closely into the date code of the > editwzards. I assumed that it was ok, because they already were patched a > lot of times. > I think, the only way to fix this is to send the numbers separately to the > client and not the UTC milliseconds. The getUTC** methods in javascript are > not the solution, because then the server has to use the date object in UTC > mode everywhere which will introdce many future headache. The server should > always be used to convert the UTC milliseconds to the separate numbers. > I don't have time to fix it now. So please add it to the bugtracker. I don't > think it is a showstopper for the upcoming release, but it is important > enough to be fixed before 1.7.1.
I added it to the Bugtracker. Personally, I think the best fix is to include in the data the timezone the client will use to edit the time. For the moment you can always send the server timezone. This would be a much more flexible solution, because then you can easily change the code if a client would like to edit in its own timezone or he might want to choose another fixed timezone, using an listbox. Only the javascripts at the client have to be changed. You can receive the data back as is done now without timezone and without changing the code for receiving data. Martijn Houtman
