You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by "Simon Kitching (JIRA)" <de...@myfaces.apache.org> on 2008/01/06 17:40:34 UTC

[jira] Commented: (TOMAHAWK-787) Incorrect display of 12-hour time in t:inputCalendar

    [ https://issues.apache.org/jira/browse/TOMAHAWK-787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12556390#action_12556390 ] 

Simon Kitching commented on TOMAHAWK-787:
-----------------------------------------

Hi Richard,

Yes you're quite right that H and h should be treated differently. The date-handling stuff has recently been completely rewritten and should now handle 12-hour time correctly. I've run the tomahawk "simple" example app, with calendar.jsp modified as follows, and it all appears to work ok:


> Incorrect display of 12-hour time in t:inputCalendar
> ----------------------------------------------------
>
>                 Key: TOMAHAWK-787
>                 URL: https://issues.apache.org/jira/browse/TOMAHAWK-787
>             Project: MyFaces Tomahawk
>          Issue Type: Bug
>          Components: Calendar
>    Affects Versions: 1.1.4-SNAPSHOT, 1.1.5-SNAPSHOT
>            Reporter: Richard J. Barbalace
>
> If the date format attribute specifies 12-hour time, as in:
>     popupDateFormat="d MMM yyyy hh:mm:ss a"
> rather than 24-hour time, as in:
>     popupDateFormat="d MMM yyyy HH:mm:ss"
> then the display from the calendar still reports 24-hour time, yielding something like this:
>     Today is 16 Nov 2006 16:23:04 AM
> That of course should read as:
>     Today is 16 Nov 2006 04:23:04 PM
> I suspect the bug involves the code beginning around line 344 of
>      core/src/main/resources/org/apache/myfaces/custom/calendar/resource/date.js
> which reads:
>         else if(patternSub.charAt(0)=='H' ||
>                 patternSub.charAt(0)=='h')
> There should probably be separate cases for 'H' and 'h', for which the latter would subtract 12 from the context.hour, but I am not familiar enough with this code to be sure.  There might also be an issue with the AM/PM setting further down the file around line 381.
> There are, in case anyone wonders why the time should be set from a calendar control, valid reasons for doing this, such as in my application where it is desired to be able to correct the date on an incorrectly entered timestamp from some other source.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.