A very commonly-used and well-known property of the DateTime structure in .NET is Now
which simply returns the current date and time on the machine executing the
code. Such a property is provided in almost all programming languages as a
built-in feature and has many applications. Unfortunately, most of the .NET
developers have been misusing this property for years for purposes other than
what it’s supposed to serve for. I can outline two possible reasons for this
problem:
· Most
of the developers are careless about all the properties and methods provided by
built-in types in a language, so they don’t discover all the details about
them. In fact, they use something that just solves their problem regardless of
the side-effects.
· The
traditional use of similar methods in languages used by .NET developers in the
past has left some bad habits for them while the internal working of this
property is slightly different from what is available in some other languages.
I have to admit that I was a developer who used to apply
this property for wrong purposes in the early years of my .NET development, and
may still misuse that for simple codes where I don’t care much about
performance, but it’s not something to use in each and every situation.
To clarify the use of the Now property
of DateTime structure I have to state that this
property is not designed to be used in cases such as when you want to retrieve
the ti
me for internal calculations in your program, store a DateTime value in database, or calculate the runtime
performance of a piece of code. In contrast, it is designed to be used when you
want to display the current date and time on a machine to your users or store
such a value in local log files where you want the local time to be used.
Although it’s hard to give a general guideline on good and
bad uses of this property, I guess that the abovementioned examples can give
you enough hints on when and where to use this property. A good question that
you may ask about this property is why we distinguish these cases and consider
some uses as bad practices. The answer is laid in the internal implementation
of the Now property shown in listing 1.
Listing 1: Internal implementation of DateTime.Now
public static DateTime Now
{
get
{
DateTime utcNow = DateTime.UtcNow;
bool isAmbiguousDst = false;
long ticks = TimeZoneInfo.GetDateTimeNowUtcOffsetFromUtc(utcNow,
out isAmbiguousDst).Ticks;
long num = utcNow.Ticks + ticks;
if (num > 3155378975999999999L)
{
return new DateTime(3155378975999999999L, DateTimeKind.Local);
}
if (num < 0L)
{
return new DateTime(0L, DateTimeKind.Local);
}
return new DateTime(num, DateTimeKind.Local, isAmbiguousDst);
}
}Essentially, this property is converting the current date
and time in UTC to the local values and has an extra processing associated with
this which is the source of the overhead that I will discuss later.
