Deprecate DateTime.Now

[ellismg]

(The original issue was at dotnet/coreclr#45), but I've moved it over here as the meat of the issue is about framework design.

From @mj1856

I would like to propose that DateTime.Now be deprecated. This is most developer's first introduction to working with time, and is also a root cause of bugs related to daylight saving time and time zones.

Developers should get in the habit of thinking globally, rather than locally - especially when designing for the web. Even on desktop and mobile applications that only run in a single time zone, this can create the kind of bugs that pull developers out of bed at 2AM on the morning of a daylight saving time transition.

More supporting arguments:

• The Case Against DateTime.Now - Matt Johnson (me)
• What's Wrong with DateTime Anyway - Jon Skeet

Given the widespread nature of this API, I suggest not removing it from coreclr - but rather marking it with an [Obsolete] attribute. I can send a PR if the suggestion is approved.

[jakesays-old]

I'm sorry but I sincerely believe this is a HORRIBLE idea. I read your "Case Against" argument - you're making all sorts of assumptions that are just not valid (or perhaps more accurately push your somewhat myopic view on time.)

While I agree there are many instances where capturing the timezone would be appropriate, it certainly isn't necessary in all cases.

Your argument that local time is without context is just false. There are many systems that operate purely within a single timezone, and the 'local' context is adequate.

I work in an industry that really pays no attention whatsoever to timezones, and we interact with data shipped from around the country. We deal with dozens of standards that do not even have room for timezone data, so having to manage it would be a complete waste of time.

Not to mention the fact that I'll now have to deal with hundreds of obsolete warnings.

[ronnyek]

Two people's ideas of what datetimes should be, automatically mean this is a bug/issue? I would strongly disagree with this change. The reality is that while I think Utc time is probably more valid/relevant date time value/format, I think the reasoning for this change is trivial. As jake points out.. .there are many .net systems out there with no concept/context of timezones or needing to run on servers.

I'd much rather have things stay the way they are... my .02c

[mattjohnsonpint]

I'm not arguing for everyone using UTC in all cases. I'm well aware of the use cases of using local time, and that many people work within a single time zone.

Let me restate the problem another way. Imagine an application that's developed offshore, as many applications are. Perhaps it was developed in a location that does not use daylight saving time, so the developers may not even be familiar with the concept. (As an example, consider UTC+05:30 that is used in India.) The application records some transactions in the local time zone on a fairly regular basis. It gets the current time using DateTime.Now, and stores it in a datetime field in a SQL Server.

Everything works well, and the application is delivered to a client in the US, or Europe, or elsewhere in the world. As an example, let's say it's installed on a server that is set to US Eastern Standard Time.

It continues to work well, until the date of the fall-back daylight saving time transition. When the clock was approaching 2:00 AM, it jumped backward to 1:00 AM and repeated the hour. How does the application behave? Well, it depends on what is done with that data. Say, for example, there is part of the application that returns records sorted by time. For this hour, it will return twice the usual amount of data, and the values from the first one-o'clock hour will be interleaved with the second one-o'clock hour. What happens from there is highly dependent on the application. Perhaps just totals are off on some report. But perhaps it triggers a false alarm on some critical tripwire.

This is just one example where ignoring the behavior of the local time zone can have unintended consequences. There doesn't need to be any concept of time zone in the application, nor does it need to have users in multiple time zones in order to encounter these types of problems. The fact is, local time is an artifact of the local time zone. In fact, we can see in the implementation of DateTime.Now that TimeZoneInfo is used with the local time zone.

In the example given, and in many of the other examples, the problem is mitigated by using DateTimeOffset.Now to get the local time including the offset - and persisting the entire DateTimeOffset object.

The only cases where you would not have these types of problems is if one of the following is true:

• The application will never run in a time zone with daylight saving time
• The application never runs in the middle of the night (near the transition times)
• The application has low activity during the transition time
• The data isn't recorded or isn't used to filter, sort, or group

In the case where you really want the current local DateTime, and one of the above is true, then you could use DateTimeOffset.Now.DateTime to be explicit that you don't care about the offset.

And yes - I agree that this is opinionated. However, I believe it's an opinion that is well informed and would help guide developers to making the right decisions. I bring it here as a proposal for discussion for the betterment of the framework - not as a bug.

[jakesays-old]

So you're suggesting the framework be optimized for offshore development? You're not, obviously, but that sure is an absurd example.

You're also dismissing 10+ years of code written around DateTime.Now. You're going to have developers maintaining code bases and arbitrarily changing Now to UtcNow to fix build warnings. Now we have a whole new raft of bugs to fix, thank you very much.

[shmuelie]

The problem is less the idea of using local time and more the fact that a developer can easily use DateTime.Now and not realize the issues. I think though that is should be more of a documentation issue than an API one. Just like string concatenation vs. StringBuilder you allow the developer to chose which is the best for their situation.

I vote for clearer documentation.

[Suchiman]

So you suppose i should always have to write DateTime.UtcNow.ToLocalTime() or DateTimeOffset.Now.DateTime everytime i need to present my user on a local operating desktop system the current time? Developers developing enterprise server applications accessed around the world should be aware of the concept of Utc.

Marking DateTime.Now as [Obsolete] will trigger a build warning with the implications of people having warnings as errors to fail the build which would be undesired and also not accurate since the concept of a local time will never fade away, the world will always have local times and requiring everyone to add explicit code to access local time would be contradictory to the basic principle of .NET to be local aware first (e.g.: string comparisons).

[mikedn]

This proposal is anything except reasonable. Yes, ideally UTC should be used but obsoleting DateTime.Now won't do that, the only thing this would achieve is making old code produce a bunch of warnings that needs to be fixed, at the cost of introducing bugs, or silenced. Or ignored, I've seen plenty of warnings ignored just like I've seen plenty of bad uses of local time.

This should be handled like other globalization issues, with code analysis tools. For example FxCop has CA1303 for string literals, something like that could probably be added for DateTime.Now.

[Clockwork-Muse]

Personally, I'd prefer a new date/time API in general (whether we ask John Skeet for NodaTime, or go with something closer to Java's new JSR310, or some third option, I don't much care - although I think NodaTime would likely need to have extensible calendars).

This is more about providing things scoped for least-use, and clearing up ambiguity.
Have a "business date", that is used globally (ie, "all sales for the 25th") - that's a LocalDate, with only year/month/day values (and note that they usually aren't strictly aligned to other calendars, either).
Have a log? Everything should be an instant in UTC, and then formatted when necessary.

...At least this isn't Java (%shudder%...that original date/time API)...

[aggsol]

What would be the alternative then? Calls like DateTime.LocalNow and DateTime.UtcNow?

[Clockwork-Muse]

You end up with different types, depending on what you're doing, usually. So stuff like LocalDate.Today (no time portion, so "now" isn't quite right), or Instant.Now (which incorporates no notion of timezones, or even year/month/day divisions - it's an offset from a specific earlier instant).

This doesn't prevent somebody from being an idiot while misusing a type, but it does allow conscientious people to be more specific and clear about what they plan to allow.

[nydehi]

it would be nice if there was a rating thumbs up or down to get the general sense of the community. oblivating aol me too message like this.

I dont think this is a good idea.

But as an aside @aggsol DateTime.LocalNow and DateTime.UtcNow are great additions but as extension methods.. there is opensource .net library for date time that is fairly popular. that would the thing to reccomend

[mattjohnsonpint]

@Suchiman - No, I'm proposing you would write DateTimeOffset.Now for that. Converting back to a DateTime defeats the purpose.

[mattjohnsonpint]

@Clockwork-Muse NodaTime is great. But I don't think introducing new types into the clr is going to stop people from misusing the existing ones.

[mattjohnsonpint]

@mikedn - yes - it would and should produce a warning. Using DateTime.Now is very easy - and is almost always in error. (Especially in an ASP.net app)

I like your idea though that perhaps this should be a Code Analysis warning instead of a compiler warning. That feels like a better balance.

[jakesays-old]

@mj1856 Can you justify your assertion that DateTime.Now is almost always in error with empirical evidence? Because honestly I have rarely come across the issues you raise, and when I have the fixes have been trivial. You're making this out to be a huge issue, and I'm just not seeing it. @SamuelEnglard pretty much hit the nail on the head - Let the developer make the decision. Contrary to popular belief we know what we're doing.