when i read it back in its gets converted again so i see 12-12-2006 18:00 you read it in and you see 12-12-2006 09:00 Thats fine for appointments but i don't want to have it everytime. sometimes the data i type in is really that date (its a literal) Example on a website:
Yeah. After waking up this morning I realized that. So the whole timezone thing should be part of a specialized component/ components then. Which is less of a head ache I guess.
"2) The first nasty thing is that pulling 12/12 through a date form, will give you a date initialized with 12/12 *but also with all time fields zero-d out*." Do you mean that you had a date (filled in with complete time) and then you format it like 12/12 and then convert it back you loose everything except the 12/12 that you entered?
No, the opposite. I'm inputting at date here before midnight (12/12, but for the Amsterdam server it is already 12/13), and initialize the value for the field with the current date. This initial value would be set to 12/12 (the client's time), but when it is saved, and you don't want to save the time zone translation as part of it (and java.util.Date doesn't have this information anyway), you have to translate this yourself so that 12/13 would be saved. Thing here is that in many instances you don't care about the time part of a date, but even though you don't care it will make a difference.
I have a solution for that i have a Stable DateConverter that works by setting the original value then apply the string that you want to parse and only the fields that are in that string are set the rest is kept as it was.
Sounds nice. Can you share? Eelco
