So, I have been talking about this topic with @drillsgt recently and also with @gerhard_boden before.
Right now our handling can be very confusing for editors in an international setting. Our DateTime editor doesn’t present you with timezones, they just do not exist. Instead the DateTime is adjusted and thought of to be in your browsers timezone. This might actually lead to unplanned (content) changes in that an editor in another timezone might change a datetime to something it was not supposed to be.
Now a possible solution would be the following:
The DateTime editor allows setting the timezone (we already save it in the properties JSON anyway). DateTimes are no longer adapted to your browser but are a “fixed” value with the timezone. You should be able to configure a default timezone for the property. For backwards compatibility the adapting to your browser behaviour could be switchable and default to on until next major with the strong suggestion to configure it in the way you want per project so you are upgrade safe. Future extensions could see default timezone per editor if that is required.
In the end this should be way less confusing and give integrators (and editors) more options to work with DateTimes.
Wouldn’t it make sense to have the default timezone be the one from the Server? At least that’s what I would expect if I set some “hiddenBefore” etc.
Exposing the TZ to the editor is a good idea but that should be optional (I assume, that that was the plan anyways)
What about dates that are not bound to a TZ, for example Birth Dates? Not sure if that’s related, but it would be cool if those properties could use the same editor but serialize to YYYY-MM-DD instead of the JSON object
Sure, why not, but IMHO having it server independent is nice, so having a configurable default might make sense. Also I would expect servers to always be UTC, while my project might mostly be in CET or so…
Absolutely, both should be possible.
perfectly fine by me, we can surely take care of that too, I would expect we create a date only editor that actually does that?
But browser-dependent instead?
I would be quite surprised if I take my laptop abroad (i.e. change my local timezone) and set a date property of a german-only website and it ends up with my local TZ – even if that’s the current default behavior (is it really?)
Really? I always configure my PHP to the local TZ and thought that was best practice…
But obviously there are sensible arguments for local timezone as well, for me they just don’t weight as much as the simple rule of all servers UTC safety.
Thanks for the initiative; this is indeed a good idea. I think it would also be a good thing to replace the time editor completely, but there seems to be a lack of decent React time pickers (also see https://github.com/neos/neos-ui/issues/1503).
Apart from the time zone issue, there are some more:
The time picker uses the Neos backend locale do determine which time format (AM/PM or 24h) to use. This was a quick fix back when 24h format didn’t work at all, but should be configurable IMO.
The minute steps are a good idea in theory, but not in practise: If you have five minute steps and set the time to “Today” ar 22:53, your steps will be 22:53, 22:58, 23:03 etc. instead of rounding up to the next 5 minutes slot.
Is this topic something we need to raise funds for?
I am very interested in a solution here as our international customers really have issues using Neos to input dates when their backend editors are located all over the world.
I could ask for some budget in my customer project to contribute here, but I suggest as first step to have a common consense about the planned solution and 2nd step some rough estimation about the effort to implement this.