Can't save dates prior to 01.01.1970 with date setting d.m.y

[Aybee]

If the "Date format" in settings is e.g. "d.m.y" you can not save birthdays before 01.01.1970. "d.m.Y" works fine. Also the datepicker interprets e.g. 31.01.70 (d.m.y) as m.d.y and thus can not find a date.

[leofeyer]

This is the expected behavior of PHP.

[discordier]

@leofeyer well, as @Aybee explained in the other ticket (as far as I understood), the PHP side IS working.

The date picker (JS side only!) goes haywire because it does not understand the value and misinterprets it. I assume we need a way to tell the format of the date to the datepicker.

[Aybee]

In the online demo go to system settings and fill in "d.m.y" in field "Date format".

Now edit a member and try to save the "Date of Birth" with 01.01.39. This will not work - shows "01.01.70" (first bug with years 39-69).

Now save the date "13.01.16" and open the date picker. It shows 01.01.1970 (second bug).

Now save the date "12.01.16" and open the date picker. It shows 01.Dec.2016 (third bug).

Now save the date "01.01.38" and open the date picker. It shows 01.01.2038 (fourth bug - birthday in future).

Maybe we should change the field "Date format" in settings to a select field and offer some values that might work.

[aschempp]

Maybe we should change the field "Date format" in settings to a select field and offer some values that might work.

Maybe we can assume a system administrator is clever enough to know that two digit years are a thing of the past?

Anyway, we can also add a save_callback on these fields and check for this specific case…

[fritzmg]

I think most of these problems stem from people not knowing, that they can and should define the frontend date format in the website root's setting, rather than in the system configuration.

[Aybee]

Maybe we can assume a system administrator is clever enough to know that two digit years are a thing of the past?

I never have used "y" in this setting. It was found by someone in the forum. Just wanted to report this one. If we offer the possibility to set a date format here IMHO it should work. Helptext says: "The date format string will be parsed with the PHP date() function."

Maybe we should not use this date format setting in BE at all. In BE we can switch to a hard coded 4 digit year date format automatically depending on the users BE language setting.

As a quick bug fixing for Contao 3.5 we can restrict this field to dmY.-/. Then it should work I think.

I think most of these problems stem from people not knowing, that they can and should define the frontend date format in the website root's setting, rather than in the system configuration.

There's no need to set up a format in the page. "d.m.Y" in settings was all I needed so far. Sometimes with another language I set the format in the page to e.g. "d/m/Y" or "m-d-Y" if the customer wants to. But we can cancel the date format field within settings and make the field in the start page mandatory or fallback to a language dependent format.

[leofeyer]

In the online demo go to system settings and fill in "d.m.y" in field "Date format".

Now edit a member and try to save the "Date of Birth" with 01.01.39. This will not work - shows "01.01.70" (first bug with years 39-69).

Woks for me.

Now save the date "13.01.16" and open the date picker. It shows 01.01.1970 (second bug).

Confirmed.

Now save the date "12.01.16" and open the date picker. It shows 01.Dec.2016 (third bug).

Confirmed.

Now save the date "01.01.38" and open the date picker. It shows 01.01.2038 (fourth bug - birthday in future).

This is correct again as stated above.

If the year falls in the range 0 (inclusive) to 69 (inclusive), 2000 is added. If the year falls in the range 70 (inclusive) to 99 (inclusive) then 1900 is added.

So 01.01.38 means 01.01.2038 and is thus correct.

[Aybee]

Now edit a member and try to save the "Date of Birth" with 01.01.39. This will not work - shows "01.01.70" (first bug with years 39-69).

Woks for me.

I've tested it again on Windows 10 with Firefox, Chrome and Opera. No chance. It always saves to 01.01.70. Can someone confirm this?

[Aybee]

This is correct again as stated above.
If the year falls in the range 0 (inclusive) to 69 (inclusive), 2000 is added. If the year falls in the range 70 (inclusive) to 99 (inclusive) then 1900 is added.
So 01.01.38 means 01.01.2038 and is thus correct.

Yes this is correct from the technical point of view. But a birthday can not be in future. The editor has no feedback, that this is 2038 and not 1938. So to prevent from such things we should not allow the use of 2 digit year format in BE.

[fritzmg]

There's no need to set up a format in the page.

Yes there is. Imagine you are running a multi language site with de and en-US for example. For the de tree you want the datetime format of the front end to be d.m.Y H:i:s for example, while for the en-US tree you might want the datetime format of the front end to be m/d/Y H:i:s.

Or imagine you do not have a multi language or multi domain site and you simply want the datetime format of the front end to be something more complicated like r (Thu, 21 Dec 2000 16:01:07 +0200). This would be an impractical datetime format for the back end.

The datetime format in the system settings serves as the datetime input format for the back end, as well as a fallback for the datetime output format of the front end, if no datetime format has been set in the site structure. Thus if you only want to change the datetime format for the front end, you should set it in the site structure and not in the system settings.

[Aybee]

Ich weiß das ja alles, aber Contao sagt im Hilfe-Wizard "Abweichende Frontend-Formate können in der Seitenstruktur erfasst werden." Und da bei mir nichts abweicht, mit d.m.Y H:i komme ich gut aus, besteht auch keine Notwendigkeit das nochmal im Startpunkt einzutragen. Ich war noch nie ein Freund von redundanten Settings. Dass ich bei Notwendigkeit, z.B. andere Sprache, im entspr. Startpunkt was eintrage, hatte ich ja oben bereits gesagt. Deine Aussage hörte sich so an, alles solle man unbedingt im Startpunkt ein Datumsformat eintragen, was so ja nicht stimmt. Habe ich auch noch nie gemacht, wenn es nicht notwendig war.

Und nochmal auf Deutsch, hatte ich oben ja bereits gesagt. IMHO sollten wir in den BE-Settings ein Dropdown mit ein paar Datumsformaten haben, welche im BE auf jeden Fall funktionieren und kein Freitext-Feld. Reicht diese Auswahl nicht fürs FE, dann kann man das in den Startpunkten ja überschreiben. Wahrscheinlich würden sich mit diesem Ansatz die Bugs von oben auch alle in Luft auflösen.

[leofeyer]

So to prevent from such things we should not allow the use of 2 digit year format in BE.

This is up to the system admin. If they want to use the 2 digit year format, we certainly should not prevent them from doing so.

[Aybee]

So we have to fix the bugs which occur when using 2 digit year format. But I'm wondering why someone should use 2 digit in BE and what it should be good for.

[discordier]

As an UNIX principle puts it:

If root desires to shoot himself into the foot, we are in no position to prevent him.

I am thinking, if someone is changing the date format like this, he better has a reason to do so.

The other two bugs however have to get addressed.

[fritzmg]

I'd vote for decoupling the system setting from the front end, to avoid confusion.

[discordier]

We can't do that because of multiple editors, different languages, locales and the like.

• System settings define a sane base.
• Page root settings may override the base with values needed for a special page tree.

There is no way to define the backend setting so that it works for all locales.

The only solution that MIGHT work IMO is to add yet another date/time setting for each user where he can define an own format, yet this will not solve your initial problem of people defining a "wrong" format but rather make it worse because now not only the admin may fuck up but also every user as well.

[fritzmg]

I merely meant that the system setting should not serve as a fallback for the front end format and thus should only serve as the back end input format.

[asaage]

Just out of curiosity: did you ever consider using datetime instead of timestamps?
I ran into the 1970 limitation several times in the past.

[discordier]

Just out of curiosity: did you ever consider using datetime instead of timestamps? I ran into the 1970 limitation several times in the past.

We did and the discussion is on the roadmap for Contao 5.0 but it is not possible to change without bc break.

However you can easily work around the 1970 problem by using unsigned integer as fieldtype. There is a ticket where I pointed this out somewhere here in the tracker.

[asaage]

Thanks for the hint. I'm aware and bookmarked this #7364 (comment)
some time ago.

Another Idea i did't came up with but saw in other software are timezones and date-formating-options in the user settings which could then override the system settings.
i would not like to see root shooting himself into the foot and dragging the other guys down with him in case of double-digit years 😉

[discordier]

If everyone can change the format for oneself, then everyone will inherit a broken setting from the admin and has to manually fix it.
Yet, everyone gains the privilege to break it for oneself... I fail to see how this will make misconfiguration more unlikely - quite the opposite - then even more pitfalls exist.

[asaage]

It could be inherited from a default and removed from the system-settings completely.
Up to now i didn't have the case of multiple backend-users with different timezones/dateformats.

[discordier]

I did so the use case exists.

If you put it that way, where should this "default" be defined when we shall remove it from the system settings?

[asaage]

like here..?
https://github.com/contao/core/blob/master/system/config/default.php#L71-L74
https://github.com/contao/core-bundle/blob/master/src/Resources/contao/config/default.php#L22-L25

and then move https://github.com/contao/core/blob/master/system/modules/core/dca/tl_settings.php#L47-L72 to dca/tl_user.php and probably add some magic - if that makes sense.

[discordier]

Ehm, you are aware that both are effectively the same? default.php is the default for localconfig.php which gets configured via the backend using the dca file tl_settings.php.

so what you were referring to is the system settings you previously suggested to remove.

[asaage]

Yes I am aware. I meant to move it from The BE->System->Setting to the BE->User->PersonalData

[leofeyer]

After some debugging I found out that this issue is not related to Contao or the date picker but to the JavaScript Date.parse() function.

console.log(Date.parse('13.01.16'));
1 Thu Jan 01 1970 01:00:00 GMT+0100 (CET)

console.log(Date.parse('13.01.2016'));
1 Wed Jan 13 2016 00:00:00 GMT+0100 (CET)

console.log(Date.parse('12.01.16'));
1 Thu Dec 01 2016 00:00:00 GMT+0100 (CET)

console.log(Date.parse('12.01.2016'));
1 Tue Jan 12 2016 00:00:00 GMT+0100 (CET)

I don't think we can easily fix this, can we?

[discordier]

You will have to alter the implementation to not use Date.parse when providing a date which can not be parsed by that method. It expects the input string to be of a defined value, however, we are providing it with something entirely different.
Therefore the datepicker must be made aware of the format in use and transcode that to a value Date.parse()is capable of understanding.

[aschempp]

http://momentjs.com/docs/#/parsing/string-format/

[Aybee]

not related to Contao or the date picker but to the JavaScript Date.parse() function.

JS returns NaN on Date.parse(13.01.16) 13.01.2016, 12.01.(20)16. Your return value seems to come from MooTools.

[leofeyer]

Your return value seems to come from MooTools.

That is correct, actually.

[leofeyer]

Fixed in 1150eb9.

[Aybee]

Figured out now that this also did not work with date settings d.m.Y in Contao 3.5.28.

Edit: Oops, I was in events startdate. It works with member birthday but not in events startdate.