-2

Our company has customers in different time-zones, so our app has to store times in a common standard although app users need to see the time using their time zone.

Whatever local zone it is when time being presented to the user, the value of the time they have edited using their timezone has to be converted back to UTC for storage so that UTC time can be presented to other users using their time zone, and then the time the other users have edited using their time zone has to be converted back to UTC for storage, and so on.

Is there a straight forward way to do that? Didn't see answers in How to convert DateTime in Specific timezone

e.g., The time value picked in my datetime-picker is 2018-08-22 13:30:00 my local time.

Jenna Leaf
  • 2,255
  • 21
  • 29
  • 1
    This isn't a question... and I dispute the statement in the first place: "We cannot store time values in user's local standard time because their time zone's time can be different than yours in your time zone." You could *absolutely* store both the local time for the user *and* their time zone... and there are good reasons for doing so, potentially - see https://codeblog.jonskeet.uk/2019/03/27/storing-utc-is-not-a-silver-bullet/ – Jon Skeet Apr 25 '23 at 15:43
  • Since @JonSkeet is involved let me do the advertisment, you can check out https://nodatime.org/ – Rand Random Apr 25 '23 at 15:58
  • As an aside, UTC doesn't stand for "Universal-time-conversion" either... It stands for [Coordinated Universal Time](https://en.wikipedia.org/wiki/Coordinated_Universal_Time) - the Wikipedia page explains why that's quite a bizarre abbreviation for it... – Jon Skeet Apr 25 '23 at 16:37
  • I looked at the link you posted saying it is a duplicate. I looked at it before: those answers do not accomplish the objective in my question nor their question has the same goal as mine! Please reopen the post. Thanks! – Jenna Leaf Apr 25 '23 at 17:30

1 Answers1

-1

For these time zone conversions to preserve the integrity, these 2 conversions HAVE TO HAPPEN TOGETHER (work in pair) in each web/app session AND use the same TimeZoneInfo.Local in both conversion directions as parameter so to preserve the time-value integrity (avoid discrepancies) !

These TWO have to work in pair to preserve the time integrity :

 //DateTime dtUTC = (DateTime)sqlrdr["editTimeUTC"];
 //From storage to the user
 DateTime dtHERE = TimeZoneInfo.ConvertTime(dtUTC, TimeZoneInfo.Utc, TimeZoneInfo.Local);
 //a new dtHERE after editing to be stored away in UTC 
 dtUTC = TimeZoneInfo.ConvertTime(dtHERE, TimeZoneInfo.Local, TimeZoneInfo.Utc);
Jenna Leaf
  • 2,255
  • 21
  • 29
  • Using `TimeZoneInfo.Local` is rarely a good idea, IMO - you claim "this is versatile in presenting any user's local time zone" but no, it uses *the system* time zone. Instead, it would be better to pass in the time zone you want to use. Also note that it's not clear what you expect to happen if the given local time is ambiguous or skipped due to time zone offset changes (e.g. daylight saving). – Jon Skeet Apr 25 '23 at 15:45
  • Jon Skeet: To answer your concern, UTC is your reference not the local time, that's why you need the round-trip UTC-to-local and local-to-UTC. You present in local, but you work on UTC. In fact, that is the only way to prevent different local time confusion. And that's what UTC conversion is for. – Jenna Leaf Apr 25 '23 at 15:55
  • No, I think you've missed both my points. First, you shouldn't generally assume that the only important time zone other than UTC is the system local time zone. How would that work when writing web app code, where the same machine serves users from multiple time zones? And you having answered the aspect of handling skipped/ambiguous times. Additionally, there's the often-ignored problem of "if I store a UTC value for a future event, what happens if the time zone rules change - e.g. a country abandons DST - between now and the event?" – Jon Skeet Apr 25 '23 at 15:59
  • @JonSkeet - `How would that work when writing web app code, where the same machine serves users from multiple time zones?` - why would the web app code, do the conversion to local time? in this example the client eg. browser should do the conversion, so the users living in different timezones would each individually convert to their respective time zones – Rand Random Apr 25 '23 at 16:09
  • @JonSkeet TimeZoneInfo.ConvertTime(dtUTC, TimeZoneInfo.Utc, TimeZoneInfo.Local) will take care of that. You always convert back to UTC to store. You do not store local time and you never do your calculation using local time. Local time is only for presentation. – Jenna Leaf Apr 25 '23 at 16:11
  • 1
    @RandRandom: You wouldn't always want to do the conversion client-side. If I'm writing a calendar app for example and want to arrange a meeting "Every Thursday at 9am Europe/London time" that's simply not something where the browser should be doing the conversion. (And you definitely *do* want to use the web server time zone, either. You almost certainly don't want to do a conversion of that to UTC at all, really, given that the offset will change over the course of the year...) – Jon Skeet Apr 25 '23 at 16:12
  • @JennaLeaf: You're still missing the point about skipped/ambiguous times, and you appear not to have read my blog post linked earlier about the dangers of storing UTC and assuming that sorts everything. Suppose I'm in London - what do you expect the conversion to UTC of 2023-10-29T01:30:00 to be... should it be 2023-10-29T00:30:00Z or 2023-10-29T01:30:00Z? (Hint: both occur at 1:30am local time...) – Jon Skeet Apr 25 '23 at 16:15
  • Whoops, that "And you definitely *do* want to use the web server time zone, either" should have been "And you definitely ***don't*** want to use the web server time zone, either". – Jon Skeet Apr 25 '23 at 16:19
  • I have edited the code and the comment. It should be alright now. – Jenna Leaf Apr 25 '23 at 19:30
  • 1
    While I definitely appreciate the edit - as the screenshot of the debugger was pointless - nothing has addressed any of my comments/concerns. This answer presents some very simple code which masks some pretty significant complexities which users should be aware of before embarking on time zone conversions. – Jon Skeet Apr 25 '23 at 19:36
  • I'm confused by your edit comment of "I listened to Jon Skeet to take out the unnecessary TimeZoneInfo.GetSystemTimeZones() line!" - I never suggested that at all... – Jon Skeet Apr 25 '23 at 19:59