DateTime.Now returns incorrect time on windows computer when time zone has changed

[WilliamSBunin]

Issue Title

DateTime.Now returns incorrect time on windows computer when time zone has changed

General

Details

I was running a windows service created in C# when I noticed my computer was set to the wrong time zone. I switched it to the correct timezone and waited for my service to do something. It did not. I restarted the service and it worked correctly. I created a test app in C# and noticed that If I change my timezone, DateTime.Now does not use the updated time. I then created a test app in .NET Core to see if it had the same behavior, and it does.

.NET Core version

.NET Core 2.1

Operating System version

Windows 10 Pro - 1903 (18362.207)

Test Code

using System;

namespace DateTimeNowTest
{
    class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine(DateTime.Now);
            Console.ReadLine();
            //Before pressing enter, change time zone
            Console.WriteLine(DateTime.Now);
        }
    }
}

[scalablecory]

iirc this was done intentionally to avoid issues with bad timing code that compares DateTime instances. You can work around it by doing this at app startup:

SystemEvents.TimeChanged += (s,e) => TimeZoneInfo.ClearCachedData();

[Clockwork-Muse]

.... What are you doing with this information?

The reason I ask is that often DateTime.Now is the wrong thing to use. Whether you want DateTimeOffset.UtcNow or DateTimeOffset.Now (or something else, even) depends on what you're using it for.

[WilliamSBunin]

We're using it with a third party software that writes local times (utc wouldn't work) to an external database.

I'll take a look at both suggestions and see if one of them works better than our current process.

Thank you

[Clockwork-Muse]

.. hopefully you're sending more than just the local time, or your stored data will be nonsense.
Assuming future dates, you need to be storing local time + offset + zone id (past dates can always be UTC). Failure to store one of these pieces will result in update errors when the DST or other offset rules change.

For ease and speed of querying, a combined type should be preferred for the first two pieces (eg, DateTimeOffset from SQL Server), as usually these will work as UTC under the covers.

[WilliamSBunin]

At this time, we are not. It's been on my list to store utc time along with the computers state location. Unfortunately, it's extremely low on the priority list. What's more, the third party application requires the local time of the computer. Until we can rewrite that along with nearly every other program that touches the database, we're stuck using local time. Whether I like it or not.

[Clockwork-Muse]

It's been on my list to store utc time along with the computers state location.

If you're dealing with future localized dates, you can't store UTC (because DST rules may change, and usually you want local time to stay the same, not the UTC instant).
If you're dealing with past/logged events, the location timezone is irrelevant to storage, although it is relevant in some reporting scenarios.

If you're talking about the US, not only do not all states observe DST, there are even some states where only part of the state observe DST. You can't just store the state, you have to store the actual zone id for the relevant party.

[WilliamSBunin]

We are dealing with future localized dates/times in one situation and in others we are not.

In that particular situation, we wait until the time hits and then perform an action. If UTC doesn't change, would it really be so bad to store. What's more, in most instances the time we are storing will take place in the same day. If DST rules did change, would they really take effect in the middle of the day?

As far as storing a zone id goes, I like it. I've added that as a suggestion to our to do list. It's interesting to think that one state can have two separate timezone for two cities right next to each other. In theory, a person could wake up at 7:30 and get to work at 7:00. Luckily, this hasn't caused any issues for us, but it might in the future.

[Clockwork-Muse]

We are dealing with future localized dates/times in one situation and in others we are not.

This is not surprising - in most cases programmers deal with logged dates, and scheduling systems will naturally contain a mix.

In that particular situation, we wait until the time hits and then perform an action. If UTC doesn't change, would it really be so bad to store. What's more, in most instances the time we are storing will take place in the same day. If DST rules did change, would they really take effect in the middle of the day?

It depends on what, semantically, "we wait until the time hits" means.

• If it's "wait until 4pm local time", that pretty obviously a localized date.
• If it's "wait until 24 hours have elapsed", that an absolute offset, and can be safely be given a UTC stamp (although pedantically leap seconds would interfere with this, support for leap seconds is spotty in general).

My recommendation is based on preserving the "domain intent". For obvious reasons, it's easier/faster to query something UTC-based, which is why the natural column is DateTimeOffset (preserves local time + offset at time of storage). The shorter the gap between queuing and firing the event, the less this violation of the domain matters. If you're only intending to serve customers in a particular country (the US?), the less the violation matters as well.

As far as storing a zone id goes, I like it. I've added that as a suggestion to our to do list. It's interesting to think that one state can have two separate timezone for two cities right next to each other. In theory, a person could wake up at 7:30 and get to work at 7:00. Luckily, this hasn't caused any issues for us, but it might in the future.

Be careful when you do: there's multiple different sets of ids, and your database may not be using the same one as your application server (and even if they are, they may not use the same version). My recommendation here is to perform all timezone-aware date-related functions in the application server only, especially if you're using a cloud provider.

---

Let's go back to this statement:

In that particular situation, we wait until the time hits and then perform an action. If UTC doesn't change, would it really be so bad to store. What's more, in most instances the time we are storing will take place in the same day. If DST rules did change, would they really take effect in the middle of the day?

(emphasis mine)

Since deciding DST is the sovereign right of each country, they can have DST take effect whenever they want, with whatever notice they want.

The record is, apparently, Haiti, with 1.5 days notice that they would abolish DST (I previously thought it was Egypt, with 3 days official notice). Note that the official update for Windows was not available for about 2 months (probably a combination of not being able to make the date regardless, and Haiti not being a large country) - although I'm not sure Linux/the IANA tzdb would have updated in time either.

There's no way to protect yourself from changes with this short of notice - in general, you're not likely to notice them in time.

[joperezr]

FYI: @tarekgh