flex-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Justin Mclean (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (FLEX-34209) DateFormatter's parseDateTime method doesn't handle AM PM properly when time is in the 12 PM hour
Date Wed, 02 Apr 2014 23:47:19 GMT

     [ https://issues.apache.org/jira/browse/FLEX-34209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Justin Mclean resolved FLEX-34209.
----------------------------------

       Resolution: Fixed
    Fix Version/s: Apache Flex 4.13.0

Checked into develop branch - final fix needed a few more minor changes.

> DateFormatter's parseDateTime method doesn't handle AM PM properly when time is in the
12 PM hour
> -------------------------------------------------------------------------------------------------
>
>                 Key: FLEX-34209
>                 URL: https://issues.apache.org/jira/browse/FLEX-34209
>             Project: Apache Flex
>          Issue Type: Bug
>    Affects Versions: Apache Flex 4.12.0
>            Reporter: Doug Pierce
>            Assignee: Justin Mclean
>             Fix For: Apache Flex 4.13.0
>
>
> DateFormatter.parseDateTime does not properly parse strings in the noon hour with an
AM or PM designator.
> For example, "2/13/2014 12:23:22 PM" does not translate to a date and instead returns
a null value.
> Upon research into this method, it appears that there is a secondary "catch all" conditional
for "Other Locales AM PM" that actually overwrites correct derivation of the "hour" value
that is used to create the return Date value:
> 				// Other lacales AM/PM 
> 				if (ampm.hasOwnProperty(word))
> 				{
> 					isPM = true;
> 					
> 					if (hour > 12)
> 						break; // error
> 					else if (hour >= 0)
> 						hour += 12;
> 				}
> This conditional does not appear to handle any time between 12:00, including, and 1:00
PM, excluding, properly as it makes the hour 24.  When the final return value is calculated,
the 24 hour actually rounds the total date value UP to the next day, resulting in a failed
date derivation validation check found near the bottom of this method:
>         // create a date object and check the validity of the input date
>         // by comparing the result with input values.
>         var newDate:Date = new Date(year, mon, day, hour, min, sec, milli);
>         if (day != newDate.getDate() || mon != newDate.getMonth())
>             return null;
> The check compares the read "day" value against the derived "getDate()" value which proves
a true value - returning null instead of the derived date.
> I'm unsure of the reasoning for the "other locales" conditional.  Therefore simply removing
it may not be the proper solution.  A better solution may be to remove the 12 value from the
conditional as so:
> 			
> 				// Other lacales AM/PM 
> 				if (ampm.hasOwnProperty(word))
> 				{
> 					isPM = true;
> 					
> 					if (hour > 12)
> 						break; // error
> 					else if (hour >= 0 && hour < 12)
> 						hour += 12;
> 				}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Mime
View raw message