Specifying the Kind on DateTime

Question

I've got a system and every object in my system has a base class with property: DateTime DateCreated

In the constructor for the base class I set the DateCreated as below:

public EntityBase()
{
    Active = true;
    DateCreated = DateTime.UtcNow;
}

This has been fine but now I'm exposing my data as json via a web service call. As the date are UTC I want the format to have the Z suffix as below:

2016-08-01T10:39:18Z

The DateCreated in each object has Kind set to Utc because I'm setting it using DateTime.UtcNow. However, as I load the data from the database the Kind remains as Unspecified (I assumed that the UTC part would be saved to the database but it appears not). When I return the dates via the web service function I get it without the Z suffix so the calling application doesn't know it is UTC:

2016-08-01T10:39:18

It seems weird to me that the UTC Kind of the DateTime object isn't saved to the database - I thought it would be. The datatype is datetime2(7).

To get the date returned as required I've changed the property in the base class to this:

private DateTime _DateCreated;
[DisplayName("Date Created")]
public DateTime DateCreated
{
    get { return _DateCreated; }
    set
    {
        _DateCreated = value;
        _DateCreated = DateTime.SpecifyKind(_DateCreated, DateTimeKind.Utc);//ensure this is set
    }
}

This does exactly what I need but seems kind of hacky - Is this really the best way?

After Googling someone suggests that using DateTimeOffset would be more appropriate. I'm not convinced? This would have me questioning the use of DateTime in any scenario - and always using DateTimeOffset!?!

Answer 1

        _DateCreated = value;
        _DateCreated = DateTime.SpecifyKind(_DateCreated, DateTimeKind.Utc);//ensure this is set

This creates a race condition: another thread can access _DateCreated in between the two assignments and get a non-UTC value. If you're going to do it at this level it should be

        _DateCreated = DateTime.SpecifyKind(value, DateTimeKind.Utc);

That leaves the question of whether it should be done at this level. You haven't said how you're getting the date from the database. Can that be configured?

---

This would have me questioning the use of DateTime in any scenario - and always using DateTimeOffset!?!

Yes. DateTime is one of those mistakes that everyone recognises is a mistake, but is so deeply embedded in so many libraries and tools that it's a pain in the neck to eradicate.

Answer 2

I'm exposing my data as json via a web service call.

You didn't say which json serializer you use but I cannot imagine you use anything else then JSON.NET. With it you can specify the date-time serializer so you don't have to implement any hacks.

string javascriptJson = JsonConvert.SerializeObject(
    entry, 
    new IsoDateTimeConverter()
);

IsoDateTimeConverter serializes a DateTime to an ISO 8601 formatted string: "2009-02-15T00:00:00Z"

See Serializing Dates in JSON for more information.

Answer 3

While you currently feel every DateTime coming to you will be in UTC, even if its DateTimeKind is not Utc, your code would be less prone to breakage from future changes, such as maybe a DateTime could be passed as Local.

Also, naming convention would be that _DateCreated should be _dateCreated.

private DateTime _dateCreated;
[DisplayName("Date Created")]
public DateTime DateCreated
{
    get { return _dateCreated; }
    set
    {
        _dateCreated = value.DateTimeKind == DateTimeKind.Unspecified
                     ? DateTime.SpecifyKind(value, DateTimeKind.Utc)
                     : value.ToUniversalTime(); //ensure this is set
    }
}

Answer 4

I use this Extension method to ""fallback" to UTC so I can properly convert between exchange time, server time and clients local time.

public static DateTime AsUTC(this DateTime dt)
 {
       switch (dt.Kind)
       {
            case DateTimeKind.Unspecified:
                return new DateTime(dt.Ticks, DateTimeKind.Utc);
            case DateTimeKind.Utc:
                return dt;
            case DateTimeKind.Local:
                return dt.ToUniversalTime();
             default:
                throw new NotSupportedException($"The provided {dt.Kind} did not exist when delivering this model, please update to latest version to support this date time type");                    
       }
}

I have noticed that sometime the DateTime.SpecifyKind is not working as expected on a given Service pack where creat a new date time always does. The method Specify Kind is just a wrapper around the create this method anyway (when it works)

We throw the error incase the framework updated and there is a not implemented method than to just leave ambiguity in a default implementation.

When reading data from the database call

var myUtcDate= myDate.AsUTC();

As the it's a value type one doesn't update the instance, you'd have to write it in a new variable.

alternatively you can do something like this when reading:

someClass.MyDateValue = reader.GetDateTime("FieldName").AsUTC();