To be understood DateTimeOffset has an offset not timezone (e.g. -08:00) For different countries the daylight saving time can be different. If local time is 2016-03-15 12:00am then the UTC for some countries can be different (04:00am or 05:00am) in DST period. So in this case the UTC I can get from DateTimeOffset could be wrong because I don't know for which country (TimeZone) is it.
E.g. (UTC-08:00) Pacific Time (US and Canada), DST: Second Sunday March <-> First Sunday November and (UTC-08:00) Baja California, DST: First Sunday April <-> Last Sunday October That's reason why we cannot use DateTimeOffset for instant values. On Wednesday, 25 January 2017 11:09:45 UTC, Denis Pujdak wrote: > > From http://blog.nodatime.org/2011/08/what-wrong-with-datetime-anyway.html > > *DateTimeOffset also isn't a good type to use if you want to tie yourself > to a specific time zone, because it has no idea of the time zone which gave > the relevant offset in the first place. As of .NET 3.5 there's a pretty > reasonable TimeZoneInfo class, but no type which talks about "a local time > in a particular time zone". So with DateTimeOffset you know what that > particular time is in some unspecified time zone, but you don't know what > the local time will be a minute later, as the offset for that time zone > could change (usually due to daylight saving time changes).* > > > On Tuesday, 24 January 2017 19:48:26 UTC, Oskar Berggren wrote: >> >> >> By the way, "Instant" sounds closely related to the existing .Net type >> DateTimeOffset. >> >> /Oskar >> >> -- You received this message because you are subscribed to the Google Groups "nhusers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/nhusers. For more options, visit https://groups.google.com/d/optout.
