I don't know if this is relevant to your problem anymore, but anyway: The DateTimeOffset contains a time AND it's offset from UTC. Therefore the corresponding UTC time can be calculated easily by just subtracting the offset. This is accomplished by several methods available on the DTO class. It doesn't matter if the local time came from two different timezones with the same or different offsets. Calculating the UTC value for the same instant is unambiguous and doesn't require a timezone.
Suggest reading the documentation here: https://msdn.microsoft.com/en-us/library/system. datetimeoffset(v=vs.110).aspx And: https://msdn.microsoft.com/en-us/library/system.datetimeoffset. touniversaltime(v=vs.110).aspx https://msdn.microsoft.com/en-us/library/system. datetimeoffset.utcdatetime(v=vs.110).aspx If you want to express the instant represented by a DTO as local time in some specific timezone, then yes, you would of course need to have the TimeZoneInfo for the target timezone. This link is also useful. Among other things, it points out that DateTimeOffset is the most useful "default" type for representing instants in time: https://msdn.microsoft.com/en-us/library/bb384267(v=vs.110).aspx /Oskar Den 26 jan. 2017 1:11 em skrev "Denis Pujdak" <[email protected]>: 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]>: > > 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-dateti >>> me-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 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.
