You are viewing a plain text version of this content. The canonical link for it is here.

Posted to users@myfaces.apache.org by Volker Weber <us...@weber-oldenburg.de> on 2005/10/04 19:22:35 UTC

Re: MYFACES-656

Hello Boris,

after thinking a bit about this problem and testing today i think best
solution is to provide a bean with a getter for your timeZone.

you can implement it like this

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

and use it

<f:convertDateTime timeZone="#{bean.timeZone}"  .../>

that sould work for you, in my tests it does.

If you do this your Date object holds internaly GMT,
maybe you must consider this when you store the date anywhere.

Boris Kovalenko wrote:
> 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.

> solves the situation. But getID() returns (for me) Asia/Yekaterinburg
> which is not recognized by JSF (imho).

"Asia/Yekaterinburg" is recognized by my java implementation,
if you got this from TimeZone.getDefault().getId() it should be recongnized.

> 
> With respect,
>     Boris
> 

Regards
Volker
-- 
Don't answer to From: address!
Mail to this account are droped if not recieved via mailinglist.
To contact me direct create the mail address by
concatenating my forename to my senders domain.

Re: MYFACES-656

Posted by Boris Kovalenko <bo...@tagnet.ru>.

Volker Weber wrote:
Hello!

>if only for the old ones it seems that your old dates in the database
>are not GMT based.
>  
>
Ok, I will check and read DB docs more carefull. No problems, as I still 
use test DB so I can convert and test anything.

>
>  
>
>>Hmmm... when I directly use Asia/Yekaterinburg it works without problem
>>and does not when <%= TimeZone.getDefault().getID() %>
>>    
>>
>
>Hmm, did this worked for you? My container (tomcat5.5.x) does not allow
>such an expression in faces tag attributes.
>  
>
I can't say this worked for me, but my container (Resin-3.0.14) does not 
complain about any errors.

P.S. And again, big thanks for your help.

With respect,
    Boris

Re: MYFACES-656

Posted by Volker Weber <us...@weber-oldenburg.de>.

Hello,

Boris Kovalenko wrote:
> Hello!
...
> 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?

Is that only for old values or also for the new ones (created by the new
applicateion with the correced converter)?
if only for the old ones it seems that your old dates in the database
are not GMT based.

Did you access the sql database also by other ways than java? If not,
or, if mainly not, i suggest to convert them to GMT.

>From java.util.Date javadoc :

... the Date class is intended to reflect coordinated universal time
(UTC), ...

And UTC is nearly GMT.

> Hmmm... when I directly use Asia/Yekaterinburg it works without problem
> and does not when <%= TimeZone.getDefault().getID() %>

Hmm, did this worked for you? My container (tomcat5.5.x) does not allow
such an expression in faces tag attributes.

> 
> With respect,
>     Boris
> 

Regards

volker

-- 
Don't answer to From: address!
Mail to this account are droped if not recieved via mailinglist.
To contact me direct create the mail address by
concatenating my forename to my senders domain.

Re: MYFACES-656

Posted by Boris Kovalenko <bo...@tagnet.ru>.

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

Re: MYFACES-656

Posted by Volker Weber <us...@weber-oldenburg.de>.

Hello,

Boris Kovalenko wrote:
> Volker Weber wrote:
> Hello!
> 
>> you can implement it like this
>>
>> public Date getTimeZone() { return TimeZone.getDefault();}
>>  
>>
> 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.

> 
>>  
>>
>> "Asia/Yekaterinburg" is recognized by my java implementation,
>>  
>>
> Hmm... I use 1.4.2_04, will upgrade to the latest 1.4.2_09 and check.
> Unfortunatelly I can not use 1.5 due some reasons. Also have You tried
> it with JSF or just test class?
> 
>> if you got this from TimeZone.getDefault().getId() it should be
>> recongnized.
>>  
>>
> 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
>>  
>>
> 

-- 
Don't answer to From: address!
Mail to this account are droped if not recieved via mailinglist.
To contact me direct create the mail address by
concatenating my forename to my senders domain.

Re: MYFACES-656

Posted by Boris Kovalenko <bo...@tagnet.ru>.

Volker Weber wrote:
Hello!

>you can implement it like this
>
>public Date getTimeZone() { return TimeZone.getDefault();}
>  
>
Hmm... but TimeZone.getDefault() returns type of TimeZone, not the Date!

>  
>
>"Asia/Yekaterinburg" is recognized by my java implementation,
>  
>
Hmm... I use 1.4.2_04, will upgrade to the latest 1.4.2_09 and check. 
Unfortunatelly I can not use 1.5 due some reasons. Also have You tried 
it with JSF or just test class?

>if you got this from TimeZone.getDefault().getId() it should be recongnized.
>  
>
But it didn't. May be this is JVM bug.

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
>  
>