Quickr #fail with dd/mm/yyyy
The latest Quickr bug I hit. posting here because I think more IBMers read Planet Lotus than the partner forum.
Steps to Reproduce:
- Set up server and client correctly running in dd/mm/yyyy date format, as per normal in the UK
- Create documents in a Quickr place at various dates in the month, some before the 12th, some after the 12th.
- Observe correct creation dates for all documents in the view.
- Open the documents and observe apparently correct dates for dd<=12
- Observe incorrect dates in 2010 or 2011 for dd>12 such as 25/03/2009 turning into 01/03/2011
in the URL bar type
javascript:alert(QuickrDateUtil.convertStringToDate(“25/03/2009″)
and in the alert box you will see the wrong date.
Now, to shift the blame away from Quickr for just a second (don’t worry it will go back), try this one
javascript:alert(new Date(“25/03/2009″))
So Javascript itself is generating the odd date. There is some logic to it, but not much. If you consider 25/03/2009 to be in mm/dd/yyyy format then it is interpreting this to mean the third day of the twenty fifth month of 2009. Which is January 2011.
So the Quickr code in QuickrCommon.js QuickrDateUtil.convertStringToDate starts by passing the date as a string to Javascript to parse by creating a new Date object. If the returned object has a year component then convertStringToDate just returns the date that javascript parsed, even if it is mad.
So why do dates dd<=12 seem to work? Well they hit exactly the same bug when Javascript mis-creates the date object. For example if the document created date is 09/03/2009 then at line 7110 of the document opened through the qpbase form dCreated will be set to something like Thu Sep 03 2009 18:34:41 GMT+0100 (GMT) as it interpreted the date backwards. Then we move on to QuickrDateUtil.getDateTimeString which then uses DoJo to format the date in mm/dd/yyyy format thereby swapping it back again (two wrongs make a right). Quickr passes the locale of “en” to DoJo but not the date pattern of dd/mm/yyyy therefore DoJo uses the default locale date pattern for en which is mm/dd/yyyy (in something like /dojo/trunk/cldr/nls/en/gregorian.js)
So Javascript new Date(string) does not use the locale information, it uses ISO date format and others including mm/dd/yyyy, it will never use dd/mm/yyyy because something formatted as dd/mm/yyyy can always be interpreted as mm/dd/yyyy if mm is permitted to be more than 12.
Quickr javascript fails to account for this and also uses DoJo to format the displayed date in mm/dd/yyyy format thereby masking the problem where dd<=12.
(whilst you are on a tour of Quickr Javascript libraries be sure to visit qp_write_html.js and check the comment on line 491)
Work Around:
maybe patch the QuickrCommon.js file to correctly parse the date, that would leave everything in American format though. At least the dates would be understandably wrong. One could then patch the DoJo en locale file to put it in dd/mm/yyyy format. Really IBM need to recode it to correctly parse the date and correctly pass the date pattern to DoJo’s gregorian calendar handling routines.
This would appear to be a regression introduced between QPBuild=20080317.1550 and QPBuild=20080407.1630
Interesting problem.
Our of curiosity, could you have upgraded with an incorrect patch version meant for the US and not UK?
no, I don’t think so. I don’t think UK and US have ever been different regions as far as fixpacks go. Whoever wrote this code clearly intended it to work for multiple locales, they just made two rather big errors which unfortunately sort of cancel each other out at the start of every month, which is probably how it got missed in the QA process.