form validates the wrong date format #5238

Closed
magicsepp opened this Issue Jan 11, 2013 · 14 comments

Projects

None yet

3 participants

@magicsepp

Hi Leo,

setting the site structure - global settings on the demo to german format by using d.m.Y etc. produce anyway a "Please enter the date as "YYYY-MM-DD"! warning on a mandatory date check text field.
For reproductioon go to site strucure and set the global settings to
Date format: d.m.Y Time format: H:i and finaly Date & Time to D.m.Y H:i
Add a mandatory textfiled with date check to the form generator "Term paper submission"
now you can enter a name and an email adress anf f.e. 01.01.2013 to the new date filed and press submit....
The expected behaviour should be a check for d.m.Y as entered in the ste structure.

Thanks a lot

@leofeyer
Member

Site structure = front end, back end settings = back end.

@leofeyer leofeyer closed this Jan 11, 2013
@magicsepp

So the question is why doesn't the front end settings not work in the front end??

@xchs
Contributor
xchs commented Jan 12, 2013

I tracked this down as follows:

  • The date/time format given in the error message you get ( Please enter the date as "YYYY-MM-DD"! ) relies on the system default settings or – in case you changed the global date and time settings in the back end system settings – on those values you've set there (and which are written to system/config/localconfig.php and override the default presettings)
  • The regex input validation for date and time formats is done in the Widget and Date classes:

To cut a long story short, the form input validation relies on the back end system settings. Therefore, you would have to set the preferred date/time format there.

Anyway, I agree that for multilingual websites this could lead to some confusion.

@leofeyer leofeyer reopened this Jan 12, 2013
@leofeyer
Member

Fixed in a7cdf43.

@leofeyer leofeyer closed this Jan 14, 2013
@leofeyer
Member
leofeyer commented Feb 1, 2013

Nope, that was wrong. You cannot use the front end date format, because the front end supports textual date formats which the back end cannot handle. Will have to revert this change.

@leofeyer leofeyer reopened this Feb 1, 2013
@leofeyer
Member
leofeyer commented Feb 1, 2013

Reverted in 2576ef9.

@leofeyer leofeyer closed this Feb 1, 2013
@xchs
Contributor
xchs commented Feb 1, 2013

Since you reverted the changes: does this mean that the mentioned issue in this topic still exists? That is, we get on an English page of our multilingual web site the error message "Please enter the date as "DD.MM.YYYY"!" if the global date/time system settings in the back end is set to $GLOBALS['TL_CONFIG']['dateFormat'] = 'd.m.Y';, right?

@leofeyer
Member
leofeyer commented Feb 2, 2013

True, but is this so much of a problem?

Another possible workaround was to check whether the front end date format is numeric and only fall back to the back end date format if it is not. But we can also ask the user to enter a date in a different format than it is output, can't we?

@magicsepp

Asking for a diffrent format is not user friendly

@leofeyer
Member
leofeyer commented Feb 2, 2013

Asking for a diffrent format is not user friendly

I do not agree at all. If a date is shown as "February 24th, 2012", it is a lot more user friendly to allow users to enter the date as "2/24/12" than to force them to enter the textual version.

@magicsepp

Leo, for such a case you are right. For such a format the template can be used to show a more readable date.
However for a german formated date d.m.Y an input with f.e. "YYYY-MM-DD" is confusing, isn't it?

@leofeyer
Member
leofeyer commented Feb 3, 2013

That is why I pointed out a possible workaround above.

@leofeyer leofeyer reopened this Feb 3, 2013
@leofeyer
Member
leofeyer commented Feb 4, 2013

Fixed as discussed in 000659b.

@leofeyer leofeyer closed this Feb 4, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment