Add Timezone Functionality to Date Time field

[6TELOIV]

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

• 2sxc version(s): 16.07.00
• Browser: all
• DNN: 9.13.2
• Hosting platform: azure
• Language: English

[iJungleboy]

@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?

[6TELOIV]

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:

1. Make the users enter the time in UTC. Most users don't know this off the top of their heads, and with Daylight Savings time the calculations get even more complicated, requiring users to use outside tools like World Time Buddy to enter their date times. This is not ideal for the user.

2. Assume users are all in one timezone, and treat the datetimes as such. This is the approach we are using, because currently all of our users are in one TZ so for them if they enter "5PM on June 3rd" then it will work as they expect. However, our server is not necessarily running in the same TZ, so the serverside code gets slightly complicated to treat these dates as a specific zone (in our case, Eastern Standard Time)

   @{
       var expires = TimeZoneInfo.ConvertTimeToUtc(
           MyItem.DateTime("Expires"),
           TimeZoneInfo.FindSystemTimeZoneById("Eastern Standard Time")
       );
   }
   @if (expires > DateTime.UtcNow) {
       <!-- Display the item -->
   }

   Compare this to the code if the datetime is stored as UTC:

   @if (MyItem.DateTime("Expires") > DateTime.UtcNow) {
       <!-- Display the item -->
   }

   Additionally, if we have users editing from another timezone, or entering details for an event in another timezone (Say Central European Summer Time, instead of Eastern Standard Time), they have to first convert the datetime into the predefined timezone we choose as developers. Timezones are complex, so this likely means using a site like World Time Buddy, meaning we've eliminated the usability issue only for a subset of users and events.

The ability to choose a timezone would allow all users to enter dates intuitively, and developers to utilize those dates intuitively as well.

[6TELOIV]

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.

[iJungleboy]

@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.
So it will only happen if someone else volunteers.

[6TELOIV]

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?

[iJungleboy]

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.

[iJungleboy]

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...