Den 26 jan. 2017 2:11 em skrev "Michael Powell" <[email protected]>:
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. I sort of agree. To my mind there are only two useful ways to store instants. Either as UTC, or as time+offset. The first is cleaner if you don't actually need to remember the offset other than for conversion to UTC, but one benefit from storing offset is that it makes it more visible that this is something you as the developer or DBA need to be mindful of. It's quite easy to forget the conversion otherwise, or accidentally storing local time without offset when it really should have been UTC. /Oskar > 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. -- 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.
