1

I have a windows applications which are deployed as remoteapp. I'm trying to generate a timestamp using C# DateTime.Now. I'm interested to know, how the timestamp will be generated, in case of user who is using the application from a place having different timezone than that of server which is hosting the application. Will it be the server specific or the user machine specific. If it is according to server timezone, is there any way to make it user machine specific?

Manish
  • 37
  • 3
  • All the comments are helpful and has lot of information. However I think I should add some more details regarding how I'm going to use it. I'm trying to capture the timestamp here to calculate the due date, which has to be exactly after 24 hours in their respective time zones. This is not going to serve any kind of audit field. So liked the idea of time zone redirection policy, as well as capturing the time zone along with timestamp. – Manish Oct 02 '17 at 17:10

3 Answers3

5

I'm trying to generate a timestamp using C# DateTime.Now.

It's strongly recommend against doing that. That will use the time zone of the system where the code is running. It's just not suitable for a timestamp. In particular:

  • Unless you also record the UTC offset, you won't know when the event actually occurred in any particularly meaningful way, including comparing one timestamp with another that might have been captured in a different time zone
  • You'll find that timestamps can go backwards in time due to time zone transitions

Instead, use UTC for all timestamps - so DateTime.UtcNow - and make sure that everywhere that uses those timestamps knows they're in UTC.

Even when using UTC, if you're using DateTime.UtcNow the timestamps will be based on the system clock, so if they're generated on multiple machines that might have system clocks that aren't synchronized with each other, your timestamps won't give a definitive ordering... but you'll be in a lot better position than just using the system local time zone.

Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
  • Thanks for the heads up! I will remember that! Could you upvote my comment good sir? – EgMusic Sep 29 '17 at 14:11
  • @ChaseBarnes: It's best not to request upvotes. (And why would you ask for an upvote for a *comment* anyway? It's not like that gives you any rep...) – Jon Skeet Sep 29 '17 at 14:11
  • @Jon_Skeet Okay. I understand. I wish you congratulations when you reach 1,000,000 rep! – EgMusic Sep 29 '17 at 14:34
  • @JonSkeet - While of course I agree with you in general, within the context of RemoteApp, this may not be applicable. RemoteApp has a feature for Time Zone Redirection, wherein the client time zone is applied to the server's clock, thus affecting `DateTime.Now` for the duration of the session. I'll add an answer on this shortly... – Matt Johnson-Pint Sep 29 '17 at 16:19
  • @MattJohnson: That still means that you can't compare timestamps from different clients, or look at a timestamp later on and know when it actually happened. (Unless the client time zone is captured too.) Basically I'd give the same advice even if RemoteApp weren't involved and this was just multiple client machines running the code - which would give the same result, if I understand you correctly. – Jon Skeet Sep 29 '17 at 16:35
  • Sure, I suppose it all depends on what the program is doing. If they are capturing a timestamp for later comparison, then of course your point makes sense. But often in the case of desktop apps we need to show the end-user their own local time. I think `DateTimeOffset.Now` with time zone redirection enabled makes the most sense here. – Matt Johnson-Pint Sep 29 '17 at 16:38
  • @MattJohnson: Maybe. I tend to think that *capturing* the timestamp in UTC and then treating "display in local time" as a display concern is generally cleaner (for example, you may well want to display a timestamp generated on another client). Of course, if you can actually store the whole `DateTimeOffset` and you *care* about the zone offset, that's reasonable and preserves more information... – Jon Skeet Sep 29 '17 at 16:43
  • 'Unless you also record the time zone' - offset may be a better choice than TZ, because of DST (and the places that use n:30, or n:45 offsets which Windows doesn't have timezones for). – tymtam Oct 02 '17 at 13:01
  • @mayu: True and edited. (Although if Windows doesn't have a time zone representing the value, then you won't obtain the right offset to start with if you're using Windows to start with. And if you're not using Windows to start with, you'd need an IANA time zone implementation anyway, which would have the relevant zones for places like Nepal.) – Jon Skeet Oct 02 '17 at 13:03
0

I'll recommend two things:

  1. Enable the time zone redirection policy on the Windows Server hosting your RemoteApp. This will allow the RemoteApp to use the client's local time zone.

  2. Update your code to use DateTimeOffset.Now rather than DateTime.Now. This will retain your offset from UTC, such that you can compare timestamps later, while still using the local values for display.

Matt Johnson-Pint
  • 230,703
  • 74
  • 448
  • 575
0

To answer your question: If you use DateTime.Now the generated timestamp will be in the local timezone of the machine the code runs on.

If you are sharing the timestamp with the server and use it for more than just displaying a local time, do not use DateTime.Now. It will cause you a lot of trouble later on.

If you want to use the build-in .NET Framework types, I recommend using DateTime.UtcNow to generate the timestamp. Whenever you want to display it, you can call DateTime.ToLocalTime() on the client system to get a local representation of the timestamp.

I would recommend using NodaTime to handle time related data, as it enforces a better handling of date and time data due to its specialized types.

Jon Skeet once held a great talk about time handling, which you can find here.

DeveloperExceptionError
  • 689
  • 11
  • 22