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.
VL2RC3 F version/ J173
Same error when it s %d/%m/%y config
with %m/%d/%y --> no error
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.
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
VL2RC3 F version/ J173
Thanks Patrick for the explanation,
so,
Quote from: Electrocity on December 07, 2011, 18:56:47 PM
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:
Quote from: Electrocity on December 07, 2011, 18:56:47 PM
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.
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
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
COM_VIRTUEMART_DATE_FORMAT_INPUT="%m.%d.%y"
COM_VIRTUEMART_DATE_FORMAT_INPUT_J16="m.d.y"
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