Date picker date format should be configurable

[GoogleCodeExporter]

The format used by the date picker is currently fixed to ISO (yyyy-mm-dd) but 
it should be flexible. This needs modifications both to the data entry helper 
and a thorough check of the impact on the Warehouse.

Original issue reported on code.google.com by johnvanb...@gmail.com on 29 Dec 2010 at 1:57

[GoogleCodeExporter]

I agree casual users will find the yyy-mm-dd format off-putting and this change 
would be of value. Most UK public expect dd-mm-yyyy.

Is it worth considering keeping yyyy-mm-dd as a standard backend system format 
and supporting a configurable display/presentation/input format for the 
front-end? This would give a predictable date format for the warehouse and 
might reduce the back end changes and risks? The configuration and conversion 
could perhaps be done in the client helpers? If these helpers are also used for 
the warehouse admin screens, as I guess they are, then these would also be 
configurable for familiar date styles. But no changes to the webservices or the 
warehouse proper.

Original comment by randomdo...@gmail.com on 3 Mar 2011 at 1:09

[GoogleCodeExporter]

I fully agree. The problem though is that the PHP strtodate implementation, 
whilst very powerful, has some quirks which need to be worked around carefully. 
In theory it is supposed to prefer a European date format if . is supplied as a 
delimiter, ISO if the delimiter is -, and American if the delimiter is /. The 
user will not understand these differences so I'd suggest having a 
configuration in the client helpers for preferred input format (EU or US). Then 
we can change the delimeter as appropriate before passing the date to 
strtotime. The problem I have found with this approach is that 
strtotime('11.12.10') with a 2 digit year just returns today's date, the . 
separator seems to only work with a 4 digit year. I guess we could easily 
enforce a 4 digit year though.

Original comment by johnvanb...@gmail.com on 3 Mar 2011 at 9:05

[GoogleCodeExporter]

I found the strtotime('11.12.10') behaviour startling, so looked into it. It 
seems it's a documented feature, see 
http://www.php.net/manual/en/datetime.formats.date.php which states

"The "Day, month and two digit year, with dots or tabs" format (dd [.\t] mm "." 
yy) only works for the year values 61 (inclusive) to 99 (inclusive) - outside 
those years the time format "HH [.:] MM [.:] SS" has precedence."

So it mistakes your date for a time, just gone 11 O'clock on the current day. 
So it looks like it is necessary to force a 4 digit year with this format.

Original comment by randomdo...@gmail.com on 9 Mar 2011 at 5:06

[GoogleCodeExporter]

I've tried switching the default format to dd/mm/yyyy and that seems to work 
fine, with a config to allow the format to be changed (though you would of 
course need to check it works). The problem is you need a date format that 
works for both PHP and JavaScript otherwise the date validation in jQuery won't 
work. 

Original comment by johnvanb...@gmail.com on 9 Mar 2011 at 8:05