The DatePicker does not support DateTimeOffset. However, Microsoft recommends using DateTimeOffset over DateTimePicker as you can see here:
These uses for DateTimeOffset values are much more common than those for DateTime values. As a result, DateTimeOffset should be considered the default date and time type for application development.
Also, DatePicker with InLine="true" hides html elements that follow. If you try to add the previous components after the one with InLine="true" in the DatePicker example you get this result:
Curious if this had been addressed yet? I just tried putting a DatePicker against a DateTimeOffset and it doesn't work, even if I specify the type directly.
there are many cases where Date Time will fail due to its failure to handle time zones correctly.
also many cloud based servers operate in the utc zero time zone
if i update a record and my form shows the updated date time then this can be very confusing to the user
for example i add a record at 2pm local time, but now the database returning the date time has the web page showing that the record was added 5 hours in the future not at the actual local time that the record was added.
with angular .applications i have developed in the past the raw date was sent back and the control in the browser used the datetime offset and the clients time zone to show the correct local time to the user as they expected to see it.
also date time math related operations with datetime can be incorrect due to how datetime does not handle time zone data correctly.
a first step might be to allow the datetime controls to show the timezone of the datetimeoffset when that data type is persented.
also if a datetimeoffset is passed into your control then return the same type ....
if we can see the time zone displayed as part of the data it can help.
oh also if one is trying to setup a meeting where people are in different time zones this also needs date time offset so that the right time zone and time can be calculated.
while the original post is old that does not mean that it is not important.
the company i work for has offices in multiple locations and different time zones.
used correctly datetime offset allows us to handle cases where things happen in different locations and we can sort them out as to when each thing happened.
i will do what i can to contribute code to your repo if you want to take it.
but here is a very general take on what needs to happen to support it
when the application starts it needs to check the client browser for what the clients time zone offset is.
then when a datetime offset data object is pulled from a back end system if it will be displaied to the user
the date and time should be converted to the local timezone of the user.
for example if my server is running in utc / 0 offset and the client is running in eastern time zone us -4:00 time.
t
if the record was saved at 2pm eastern which is 6pm utc so the server gives me 18:00 +0:00 as the time
18:00-04:00 = 14:00 so the web page should show the user 14:00 or 2pm
dtatetimeoffset value - timezoneoffset = displayed date and time.
in most cases if the user is picking a date and time they will do that in the context of thier time zone.
so if i am in us eaastern time and i post a new date then add my timezone offset to the date time and make a datetime offset to send to the back end for storage.
yes there are some things that have to be done but its not actually that bad.
but if the date is stored with the time zone then it will work for all ocations
if a user is in california and opens the record they will see the time in thier local time zone and its 11:05am pacific which is -8 then they will see the time as 11:00am and they will see that the record was updated or created 5 minues ago..... which is correct for where they are. they do not have to look at the time zone and do the math to figure this out.
ok i know this sounds like a lot but really it comes down to respecting the users time zone and the servers time zone.
@figuerres is explaining quite well how datetimeoffset needs to be handled. For reference this is the way the now defunct Microsoft Lightswitch handled it... In fact Lighswicth was able to get from the user's browser not only timezone info but also language info (English, French, German..) It would be great to have the same feature in Radzen... but even if language is not picked up from the user's browser, picking the time zone and displaying datetimeoffset fields accordingly is essential.
This is how the application created by Radzen IDE/Radzen Blazor Studio works when you enable localization. DateTime however will be always saved in UTC by default and if you wish to change that you can use partial methods of the service/controller to modify it.
Yes, DateTimeOffset will be stored in UTC, but should not the display of that UTC time be by default in the user's time zone? Should this not be a built in feature of Radzen just like it was for Lightswitch? I am not sure I understand why you would not implement this.... How are we supposed to manage a calendar shared by an office in Berlin and an office in Montreal? People think in their own time zone, not UTC...
