Hello!

Hmm... but TimeZone.getDefault() returns type of TimeZone, not the Date!
your right, it must be

public TimeZone getTimeZone() { return TimeZone.getDefault();}

but this is the object type as expected by the timeZones valueExpression
in the converter.

Ok, this helps... now local dates are ok. Thank You, Volker! But now I have problems with dates I reading from SQL. What should I do with them? Is there best practices how to work with dates?
"Asia/Yekaterinburg" is recognized by my java implementation,
if you got this from TimeZone.getDefault().getId() it should be
recongnized.
Hmmm... when I directly use Asia/Yekaterinburg it works without problem and does not when <%= TimeZone.getDefault().getID() %>



But it didn't. May be this is JVM bug.


the jvm shouldn't return an id which is not recongnized.

you can get all valid ids by timeZone.getAvailableIDs().


Hello, Volker!


   I found, that setting timezone to normalized form (e.g. GMT+6)



With this you still have the problem to change this every half year.


Yes, but we can use something like
public int getOffset() {
/|    Calendar.get(Calendar.ZONE_OFFSET) +
Calendar.get(Calendar.DST_OFFSET)) / (60 * 1000)|./
}

As per JDK docs





With respect,
  Boris




Regards
Volker




With respect,
        Boris

Reply via email to