Tax and calculation rule doesn't work with different date format

[nicole2292]

When I have the date format set to %d/%m/%y rather than %m/%d/%y I am unable to create a new tax and calculation rule. It spits an error about the date format.

500 - An error has occurred.
DateTime::__construct(): Failed to parse time string (20/11/11) at position 0 (2): Unexpected character

This should be corrected asap as most parts of the world use the date format %d/%m/%y.

[joomlaforever]

VL2RC3 F version/ J173
Same error when it s %d/%m/%y config
with %m/%d/%y --> no error

[atb]

VL2RC3 E version/ J173
Same error when it s %d/%m/%y config
with %m/%d/%y --> no error
Hi,
It is worth noting that this bug is the creation AND EDITING of Tax rules and NOT that "Tax and calculation rule doesn't work", as implied in the thread's title.

Although it would be good to fix the bug, the simple work-around is to temporarily set back the date preference to %m/%d/%y in order to create a new item or even edit an existing item - maybe "interesting" for a live site, but OK for development/testing and offline.  Obviously it ought to be fixed, but not highest priority.

[Studio 42]

In normal case the format is not used anymore.

The order date format is set by language file now(this must be so in all views)
the setting in the config are obsolete or we forgot a Date render(and this give you then such errors)

Tks for report.

Patrick

[atb]

VL2RC3 F version/ J173

Thanks Patrick for the explanation,
so,

In normal case the format is not used anymore.
.....
the setting in the config are obsolete or we forgot a Date render(and this give you then such errors)

I presume this means that the "Shop date format" setting in "Shop Settings" should be left as default, i.e. %m/%d/%y  and, in any case, will not used for displaying (rendering) date items.

Also, a comment on:

The order date format is set by language file now(this must be so in all views)

I note that there are several date formats within "language\en_GB.com_virtuemart.ini"(both in root & \administrator), which are all set to the International format, rather than the normal UK order of dd/mm/yy.  Such settings influence aspects such as the display (render) of "Start Date" and "End Date" in the "Tax & Calculation Rule", although this uses a calendar form of entry.

So, should these date items be changed from Interntional date order to the normal UK order for en-GB?
COM_VIRTUEMART_DATE_FORMAT_INPUT_JS="y.mm.dd"
........
; THis is not valid joomla 1.7 !!!
COM_VIRTUEMART_DATE_FORMAT_LC="%A, %d %B %Y"
; Date joomla 1.5 >1.6 format changed %d is d now
COM_VIRTUEMART_DATE_FORMAT_INPUT="%y.%m.%d"
COM_VIRTUEMART_DATE_FORMAT_INPUT_J16="y.m.d"

Although there is some merit in the International date order format, it can be misleading when used to render when there is an assumption  that the date format is localised.

[Studio 42]

Code Select Expand

COM_VIRTUEMART_DATE_FORMAT_INPUT="%y.%m.%d"
COM_VIRTUEMART_DATE_FORMAT_INPUT_J16="y.m.d"
this string set the input form, first is j1.5 , second is j1.6+
He must be the Standard form

Code Select Expand

COM_VIRTUEMART_DATE_FORMAT_INPUT_JS="y.mm.dd"
in normal case this set an hidden input and have not to be modifed

in normal case the date must correspond to
http://unicode.org/cldr-apps/survey?_=en_GB&forum=en&xpath=%2F%2Fldml%2Fdates%2Fcalendars%2Fcalendar%5B%40type%3D%22gregorian%22%5D%2FdateFormats%2FdateFormatLength%5B%40type%3D%22short%22%5D%2FdateFormat%5B%40type%3D%22standard%22%5D%2Fpattern%5B%40type%3D%22standard%22%5D
and converted to the right syntax but seems some translator doesn't respect this rule.

actually the standard rule is
   M/d/yy    (9/14/99)
this give for keys in en-GB

Code Select Expand

COM_VIRTUEMART_DATE_FORMAT_INPUT="%m.%d.%y"
COM_VIRTUEMART_DATE_FORMAT_INPUT_J16="m.d.y"

[Studio 42]

The date are now all reformated by the UNICODE convention. On update from SVN or waiting next release this are now in this form for english

COM_VIRTUEMART_DATE_FORMAT_INPUT="%m.%d.%y"
COM_VIRTUEMART_DATE_FORMAT_INPUT_J16="m.d.y"
COM_VIRTUEMART_DATE_FORMAT_INPUT_JS="mm.dd.y"

input are now in en-GB for eg.>> 12.31.99
To follow unicode standard