You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by "Luka Surija (JIRA)" <de...@myfaces.apache.org> on 2007/11/14 15:22:43 UTC
[jira] Created: (TRINIDAD-817) Serious bug in tr:chooseDate
Serious bug in tr:chooseDate
----------------------------
Key: TRINIDAD-817
URL: https://issues.apache.org/jira/browse/TRINIDAD-817
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Reporter: Luka Surija
I've found a serious bug in tr:chooseDate bug. It has something to do with day light saving.
1. scenario:
<tr:inputDate value="#{myBean.date}" >
<tr:convertDateTime pattern="dd.MM.yyyy HH:mm" />
<tr:chooseDate />
</tr:inputDate>
time-zone in trinidad-config.xml doesn't matter.
initial value for myBean.date is null.
1. select: 18. August 2007 on date picker
displayed date is "18.08.2007 18:38" (18:38 is client browser time)
2. select again: 18. August 2007 on date picker
displayed date is "18.08.2007 17:37" (18:38 is client browser time)
3. select again: 18. August 2007 on date picker
displayed date is "18.08.2007 16:36" (18:38 is client browser time)
4. select again: 18. August 2007 on date picker
displayed date is "18.08.2007 15:35" (18:39 is client browser time)
etc....
2. scenario:
<tr:inputDate value="#{myBean.date}" >
<tr:convertDateTime pattern="dd.MM.yyyy" />
<tr:chooseDate />
</tr:inputDate>
initial value for myBean.date is null.
1. select: 18. August 2007 on date picker
displayed date is "18.08.2007"
2. select again: 18. August 2007 on date picker
displayed date is "17.08.2007"
3. select again: 18. August 2007 on date picker
displayed date is "17.08.2007"
4. select again: 17. August 2007 on date picker
displayed date is "16.08.2007"
etc....
My server timezone is Europe/Zagreb. Setting <time-zone>Europe/Zagreb</time-zone> in trinidad-config.xml or leaving without time-zone setting doesn't make any difference.
The same error is also on
http://www.irian.at/trinidad-demo/faces/components/inputDate.jspx
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-817) Serious bug in tr:chooseDate
Posted by "Yee-Wah Lee (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/TRINIDAD-817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12542905 ]
Yee-Wah Lee commented on TRINIDAD-817:
--------------------------------------
I debugged #1 in America/Los_Angeles time, and daylight savings ended this year on Nov 4, moving from PDT (UTC - 7) to PST (UTC - 8). I see 2 cases.
Suppose the input value currently contains Nov 15 2007 14:00 (PST).
i) Pre-daylight savings cutoff
- ChooseDateRenderer generates the Millisecond value for the date using BaseDate + (# of days * _MILLIS_IN_DAYS), and the hours/minutes/seconds are zeroed out, e.g. Nov 1 2007 00:00 PDT
- When the user selects the date, the client does the following calculation in _dfsv():
Link_milliseconds + _getDayLightSavOffset() + _getHours()
where:
_getDaylightSavOffset(): Compensates for the difference in daylight savings and the current display. In this case, the Nov 1 2007 date was in PDT but the current time is in PST so it subtracts an hour.
- _getHours() copies the hours over (14:00)
Putting it together:
[Nov 1 2007 00:00 PDT] + (-1h) + (14:00)
= Nov 1 2007 13:00 PDT, which is displayed as "Nov 1 2007 13:00", appearing to lose an hour.
ii) Post-daylight savings cutoff
- ChooseDateRenderer adds a constant factor of milliseconds, but that does not account for daylight savings. So, past Nov 4, the dates are off an hour. For example, the link for Nov 5 is generated as [Nov 4 2007 23:00 PST]
- When the user selects the date, the client does the following calculation in _dfsv():
Link_milliseconds + _getDayLightSavOffset() + _getHours()
where:
_getDaylightSavOffset(): Does not add anything because the selected date and current display are both in PST.
_getHours() copies the hours over (14:00)
Putting it together:
[Nov 4 2007 00:00 PDT] + (-1h) + (14:00)
= Nov 5 2007 13:00 PST, which is displayed as "Nov 5 2007 13:00", again appearing to lose an hour.
> Serious bug in tr:chooseDate
> ----------------------------
>
> Key: TRINIDAD-817
> URL: https://issues.apache.org/jira/browse/TRINIDAD-817
> Project: MyFaces Trinidad
> Issue Type: Bug
> Components: Components
> Reporter: Luka Surija
>
> I've found a serious bug in tr:chooseDate bug. It has something to do with day light saving.
> 1. scenario:
> <tr:inputDate value="#{myBean.date}" >
> <tr:convertDateTime pattern="dd.MM.yyyy HH:mm" />
> <tr:chooseDate />
> </tr:inputDate>
> time-zone in trinidad-config.xml doesn't matter.
> initial value for myBean.date is null.
> 1. select: 18. August 2007 on date picker
> displayed date is "18.08.2007 18:38" (18:38 is client browser time)
> 2. select again: 18. August 2007 on date picker
> displayed date is "18.08.2007 17:37" (18:38 is client browser time)
> 3. select again: 18. August 2007 on date picker
> displayed date is "18.08.2007 16:36" (18:38 is client browser time)
> 4. select again: 18. August 2007 on date picker
> displayed date is "18.08.2007 15:35" (18:39 is client browser time)
> etc....
> 2. scenario:
> <tr:inputDate value="#{myBean.date}" >
> <tr:convertDateTime pattern="dd.MM.yyyy" />
> <tr:chooseDate />
> </tr:inputDate>
> initial value for myBean.date is null.
> 1. select: 18. August 2007 on date picker
> displayed date is "18.08.2007"
> 2. select again: 18. August 2007 on date picker
> displayed date is "17.08.2007"
> 3. select again: 18. August 2007 on date picker
> displayed date is "17.08.2007"
> 4. select again: 17. August 2007 on date picker
> displayed date is "16.08.2007"
> etc....
> My server timezone is Europe/Zagreb. Setting <time-zone>Europe/Zagreb</time-zone> in trinidad-config.xml or leaving without time-zone setting doesn't make any difference.
> The same error is also on
> http://www.irian.at/trinidad-demo/faces/components/inputDate.jspx
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.