TYPO3 Core

• add "Date format" setting in the user settings
• add "Date-time format" setting in the user settings
• add "Time format" setting in the user settings
• add "Time zone" setting in the user settings
• add "Show timezone in date pickers" setting in the user settings
• refactor jsfunc.evalfield.js so it can be easily extendable (and maintainable)
  • my idea is to go with Prototype.js OOP since it's already loaded and available
• Integrate date.js parsing logic
• add support for for overriding php.ini timezone setting in LocalConfiguration.php (since it's a bad practice to store dates in "server timezone") and document best use case scenarios. Additional useful info on storing dates in MySQL: http://cdn.oreillystatic.com/en/assets/1/event/36/Time%20Zones%20and%20MySQL%20Presentation.pdf

Please refrain from creating anything new with Prototype. We try to get rid of it, please use jQuery.

jQuery is not my first choice when working with "OOP" JS. And this refactoring has very little to do with DOM (apart from maybe using jQuery to read data attributes of a DOM element - a feature I will add for detail customization of the eval logic).

Is there an suggested alternative for the TYPO3 BE? I can always use something simple like this http://ejohn.org/blog/simple-javascript-inheritance/ (which is in fact based on Prototype.js).

Hi!

Please discuss this on slack with others (I just Stucki to invite you), I'm not so much into the JS part.
Maybe talk to Andreas Wolf or Benni Mack.

Thanks

Patch set 2 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/32360

Patch set 3 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/32360

Great contribution! Indeed problems with TZ were quite annoying.
I did not have time yet to go through the patch yet, but just wanted to confirm that with your patch dates and time should Always be stored in UTC, no metter what timezone user is in, and how server is configured.

One more note: date.js has better support in parsing natural language date strings, but moment.js plays much nicer with timezones, so opted for it instead. That's why I added date input field placeholders. Moment.js will parse standard (and ISO) date formats as well as a fallback...

Anyway, if you guys and gals feel like we need natural language processing, we can add date.js as well :) My impression is that it would be too much...

Thanks for your awesome work. I will try to read through the code asap.

One question: I assume the lib supports half hour and quarter hour timezones as well, but does it support DST for all variants that are out there in the wild?
(I guess you know that funny video about time(-zone) programming)

Patch set 4 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/32360

As I said, I assumed that, but the question is about daylight saving time.
"most" countries have some certain dates where the clock is changed, but there is an awefull list of exceptions.

Check that video:
http://www.youtube.com/watch?v=-5wpm-gesOY

So maybe we should do the DST setting as a manual setting for the user.

Markus Klein wrote:

As I said, I assumed that, but the question is about daylight saving time.
"most" countries have some certain dates where the clock is changed, but there is an awefull list of exceptions.

Check that video:
http://www.youtube.com/watch?v=-5wpm-gesOY

So maybe we should do the DST setting as a manual setting for the user.

If you select a timezone (based on the usual list), it already defines if DST is in place or not and when (as you can see in the sample above for CET/CEST in Europe/Belgrade timezone). Adding a DST setting will just confuse a regular BE user. Furthermore, moment.js doesn't have a documented way of retrieving DST dates per timezone and I would refrain from hacking through it in order to allow easier upgrades in future.

Ok, I'm confused now.

How does moment.js implement DST?
According to you screenshots it deducts the DST from the timezone, but that is plain wrong. (as explained in the video, DST switching highly depends on the country/location)

I agree we shouldn't hack that on our own, I propose to disable DST handling completely (if that is possible).

Markus Klein wrote:

Ok, I'm confused now.

How does moment.js implement DST?
According to you screenshots it deducts the DST from the timezone, but that is plain wrong. (as explained in the video, DST switching highly depends on the country/location)

Yes, and selecting a timezone means selecting a location. Please take a look at the new user BE settings. This list is used: http://php.net/manual/en/timezones.php.

I agree we shouldn't hack that on our own, I propose to disable DST handling completely (if that is possible).

Moment.js automatically handles DST, the same way as PHP does.

There might be some confusion regarding this. Selecting a timezone means selecting a location - that defines DST start/end dates per year. When displaying a timezone in the field, you really don't need to see the location but time zone in format (UTC+XX:XX). Moment.js even thrown out the support for displaying timezone in the short format (like CET, CEST, PDT,...) since the browsers do not implement it consistently.

One more note, I included the moment.js timezone library with data for all years (http://momentjs.com/timezone/).

So in order to not break the existing installations there's a new setting $GLOBALS['TYPO3_CONF_VARS']['SYS']['storeDatesInUTC'] which defaults to FALSE. It is recommended to set this to TRUE on all new installations.

Can't we make it correct (UTC) by default? Especially as there are already inconsistencies in the core. This patch is targeting 6.3 anyway. In the separate patchset we could add a migration wizard to recompute the dates when sb is updating the installation.
I'm opting in for storing dates in UTC, as most people especially newcommers will forget to change this setting.

I think the patch already has this by default for new installations.

Just a side-note: When we have it "correct" in TYPO3-core, let's then look what Extbase stores and reads. I just had a nightmare with Extbase not storing DateTime-objects correctly - and when we have a defined way how to store it in DB, we can look at that part as well.

Patch set 5 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/32360

Patch set 7 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/32360

Patch set 8 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/32360

Patch set 9 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/32360

even better:
timeozne support was added to the stable branch of date picker 4.17.37
see http://eonasdan.github.io/bootstrap-datetimepicker/Changelog/

Patch set 10 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/32360

Patch set 11 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/32360

Patch set 12 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/32360

Patch set 13 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/32360

Patch set 14 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/32360

Patch set 15 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/32360

Patch set 16 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/32360

Patch set 17 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/32360

Patch set 18 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/32360

Patch set 19 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/32360

Patch set 20 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/32360

Stumbled across this again on a TYPO3 v10-system. DB correctly stores UTC, frontend correctly shows local time (according to phpTimeZone). But backend uses UTC ... which is a pain for editors to work with.

Since a lot of blockers from the past are done, for example we are now using moment.js, is having locale-aware support for the backend something we can take care of? Or are there further renovations pending for FormEngine or so that I'm not aware of, which need to be handled first before continuing this effort here?