> 1) In validator.js the date object is used in the client > timezone. I am not sure if this works correct, especially > with dtmin and dtmax. In the errormessage there is even a mix > of UTC and the local timezone > > d.getDate() + " " + (d.getMonth()+1) + " " + d.getUTCFullYear()
That is exactly what I wrote in the comment above the dtmin and dtmax. I don't know if someone uses thess options. These 2 options were not available in release 1.6. I added/fixed those with the new frontend. We might just drop it. I overlooked the UTC method. > 2) This is also the case in editwizard.jsp. Inserting a new > date happens in the client timezone, so there is still a mix > of several timezones. The javascript date object in the validator is only used to check if it is a valid date. It doesn't matter what the milliseconds are. I used the date object in the editwizard.jsp to get the Now time of the client when a new object is created. The day, month and year are send to the server. I just wanted the same behaviour as it was before. Now it does not matter where the server is. The clock on the client machine is the same as what the wizard shows. > 3) The timezone is implicit, which means that it is difficult > to change the code lateron when you don't want to use the > server timezone. When you move a site to another timezone > alle dates will change, which is not always desirable. It > would be very nice if you can set the timezone at some place. The dates stored in the database are in milliseconds. The data is timezone dependent. Server timezone independency is more a general problem not only the wizards. If we want to support this then a lot of things have to be changed. The described situation does not occur often and it is probably easier to change your data instead of the application. Nico
