Add Timezone Functionality to Date Time field about 2sxc HOT 7 OPEN

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.

from 2sxc.

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

from 2sxc.

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.

from 2sxc.

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.

from 2sxc.

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

from 2sxc.

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?

from 2sxc.

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

from 2sxc.