-
-
Notifications
You must be signed in to change notification settings - Fork 40
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Timezone Functionality to Date Time field #3362
Comments
@6TELOIV I don't quite get the issue. Could you give an example, where this is currently causing trouble? eg. what time zone are the editors in, what time are they entering and why would they want to add a time zone? |
Our current situation: Users want to schedule a post to expire after a real-world event is happening (a conference, a meeting, etc). Let's say that event is happening at 5pm local time for the user. Currently, the two options I have as a developer:
The ability to choose a timezone would allow all users to enter dates intuitively, and developers to utilize those dates intuitively as well. |
I would suggest that this could be implemented as a new Input Type of the Date Type "Date and/or Time", perhaps called "Local Date/time picker" or "Localized Date/time picker", or as an option which defaults to off on the existing input type, to avoid confusion for apps that have already done the predefined conversion as I explained above. |
@6TELOIV thx. I understand the use case. Since the data is always stored without any time zone, I believe the UI would need to provide an option to do this. It's probably not too complex - but date-time-pickers are actually quite a hassle, so despite it not looking very difficult, there are a lot of things that can go wrong. To be honest, the date-time-picker has been our most challenging input field. My estimate is that it's somewhere from 1 to 2 days work, depending on what goes wrong, and what must be fixed after initially thinking that it's solved. I don't have the resources to handle this ATM and wouldn't see that I would prioritize this any time soon. |
I think I could possibly handle this one. I assume the internal structure of input types is similar to that for user-created input types? |
Not exactly, then again much of it is actually simpler, but in a large code base ;) This is the repo: https://github.com/2sic/eav-ui You can fork it, download, npm-install and npm-build. To get the build to copy everything into your test DNN, check out these instructions https://azing.org/2sxc/r/qzEuJ8f4 If anything is unclear, I'm glad to improve the docs, so just let me know. |
There are some extra challenges to this, so I'm really not sure if it can work. Basically the UI could let the user enter the time this way, but upon loading the date is plain, without a stored additional piece of data. so even if he saves "14:00 UTC+2" it is saved as "12:00" and upon loading it would also show "12:00" since it wouldn't know what time-zone difference the user had wanted then... |
I'm submitting a
[x] feature request
...about
[x] edit experience / UI
[x] admin experience UI
[x] Content Types or data management
Current Behavior / Expected Behavior
Currently, the Date/Time input type only supports a simple entry with no timezone information. For developers, this means either accepting these as UTC and instructing editors to convert times to UTC (not ideal) or nothing the timezone of the users and converting it on the server (also not ideal and a large headache when it needs to be compared, etc). Neither of these options allows for users in different timezones to use the same UI and input the data in the form they expect.
I propose adding an option to the Date Time input to allow the end user to select the time zone of the data they input, and also default this timezone to the user's time-zone. On the data-storage side of things, the data should continue to be stored in UTC format, and would only be converted for the UI.
Instructions to Reproduce the Problem
Develop an app that needs to run on servers in different timezones and/or has editors in different timezones. Observe the development and user headaches outlined above.
Your environment
The text was updated successfully, but these errors were encountered: