DateTimeOffset contains a local time. There is no UTC (http://stackoverflow.com/questions/8343929/is-date-time-part-of-sql-servers-datetimeoffset-utc-or-local).
So if you don't know what timezone exactly is (-08:00 Pacific Time or -08:00 Baja California) you cannot get UTC correctly. On Thursday, 26 January 2017 03:20:31 UTC-7, Oskar Berggren wrote: > > No, I believe you are mistaken. > > There is only one UTC. The UTC is never different. It's value is always > the same everywhere. > > The DateTimeOffset class is used to represent a specific point in time, > and it can also store that instant associated with an offset. The stored > offset should always be the stored value's exact difference from UTC. > > So, provided that you grab the local time and the local offset currently > in effect at that time, when the DTO is constructed, it can always be > converted to an unambiguous UTC value without knowing the geopolitical time > zone information. > > For the opposite transform, that is, converting a DTO to a local time and > local offset appropriate to a specific region at that point in time, you > would need to specify what time zone information to use, obviously. You > don't need to record the time zone name unless you expressly need to > display that information later - but I didn't see you do that in your > Instant class. > > If you ask the computer for the current local DTO, it will return > different offset depending on if DST is in effect or not. Regardless, the > recorded value can be unambiguously converted to correct UTC. > > You can also have a DTO, add an hour to it, and get a new DTO which > represents a point in time exactly one hour later - BUT it might not be a > correctly expressed local time in your intended time zone, because it won't > update the offset. For that you need help from a time zone. If it's the > current timezone in effect, it should be easily achieved by just > roundtripping the DTO to UTC and back. > > > What WILL get you into trouble is if you store the local time _without_ > offset or timezone moniker (which should both change between DST and > regular), because then some values will be ambiguous. You can't tell if it > was the last hour of DST or the first hour of standard time. > > This is my understanding anyway. Happy to be corrected if I'm wrong. > > Getting back to your Instant and it's mapping. If the stored local time is > only needed for reporting, I wonder if you have considered using a view to > calculate it when needed and not bother the application with it? Or a DB > trigger to have the DB do it on UPDATE. > > > /Oskar > > > Den 25 jan. 2017 2:26 em skrev "Denis Pujdak" <[email protected] > <javascript:>>: > > Edited > > > On Wednesday, 25 January 2017 05:42:40 UTC-8, Denis Pujdak wrote: > >> 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 different countries can >> be different (08:00pm or 07:00pm) 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] <javascript:>. > To post to this group, send email to [email protected] <javascript:> > . > Visit this group at https://groups.google.com/group/nhusers. > For more options, visit https://groups.google.com/d/optout. > > > -- 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.
