On Thu, Jan 26, 2017 at 5:20 AM, Oskar Berggren <[email protected]> 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.
This is exactly correct and is why if you are storing potentially ambiguous date/time, you are asking for trouble. > 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. Never been a fan of handling offsets, per se. That's always a view concern. In web it is easy enough to convert to local time zone. Even in a report, I expect it would be easy to receive a time zone in order to the Utc to local conversion in the handshake. > 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. Agreed. In any event, I always steer clear of this confusion whenever possible. But what do I know. > 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]>: > > 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]. > 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. > > > -- > You received this message because you are subscribed to a topic in the > Google Groups "nhusers" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/nhusers/f8qa0bYPHWM/unsubscribe. > To unsubscribe from this group and all its topics, 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. -- 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.
