Runtime: TimeZones and DateTimeOffset

[vsfeedback]

_This issue has been moved from a ticket on Developer Community._

---

Currently DateTimeOffset is lacking in Options for Time Zone conversions and the windows api for TimeZoneInfo has no support for DateTimeOffset

this leads to having to write code to convert a datetime offset to a date time then useing TimeZoneInfo to convert to a new Datetime and then back to a DateTimeOffset so that the intended point in time and time zone are perserved.

this set of conversions between formats and the related api calls creates the possiblity of errors in conversion that may not be easy to spot if the developer is not fully versed in the details of time zones.

i think that a new set of methods or a new class library be created that unify the TimeZoneInfo and DateTimeOffset to allow a developer to ask that a datetimeoffset be converted to a new timezone and not need to get into a chain of conversions. this would reduce errors and make use of DateTimeOffset simpler for most developers

---

Original Comments

Denny Figuerres on 3/15/2019, 08:16 AM:

also DateTimeOffset ToLocal assume the servers date time / timezone which does not give any option to convert to a users time zone for an application on the web, the client may be in a different timezone than the browser client.

and a browser may need to see a date for a timezone they are not in.

Jane Wu [MSFT] on 3/18/2019, 01:36 AM:

Thank you for taking the time to provide your suggestion. We will do some preliminary checks to make sure we can proceed further. We'll provide an update once the issue has been triaged by the product team.

[Clockwork-Muse]

also DateTimeOffset ToLocal assume the servers date time / timezone which does not give any option to convert to a users time zone for an application on the web, the client may be in a different timezone than the browser client.

and a browser may need to see a date for a timezone they are not in.

This. This is why DateTimeKind is broken. Utc/Local/Unknown (or Other in similar APIs) show a misunderstanding of the domain.

I will reiterate that we should provide a first-party complete, modern, date/time API, that would look similar to java.time and NodaTime.
Note that in most cases DateTimeOffset is also not the proper domain type, as non-absolute-instant information is usually better recorded as a DateTimeZoned (which automatically updates the offset when adding any time).