Vikas Sardana
Vikas Sardana

Reputation: 1643

UTC offset from server to client

In our application we are Saving the UTC DateTime in DataBase. Client (javascript) is sending the datetime in Local TimeZone and at controller level we are converting it to UTC time before saving the date in Database.

Both the client and servers are on different timezones.

we are fetching date from database in UTC Using Entity Framework with

DateTime.SpecifyKind(_CreatedDate, DateTimeKind.Utc);

So should we again convert the DateTime to local DateTime at controller or should we handle all the DateTime conversion logic at the client.

Upvotes: 3

Views: 2330

Answers (3)

Anestis Kivranoglou
Anestis Kivranoglou

Reputation: 8184

Since it's quite relative when is the "Proper" time to convert.

The only absolute rule i think is valid is this one.

UTC time is the only Real meaningful data

Any other conversion to any timezone is just a "Display" for me

So follow the same rules as you would with the rest of your data.

Like converting a Boolean to a Checkbox on the view.Or sending that checkbox value as Boolean to the server.

And that's the soonest it Reaches or Leaves the UI.

Upvotes: 1

Brandon
Brandon

Reputation: 3276

Here's the way we do it in our projects. In my opinion, you should be using datetimeoffset in your database. This allows you to be able to identify what timezone the date was saved in. Then, when you send your date from your client to your server, just make sure it's sent in datetimeoffset.

When you send the datetimeoffset from the server to the client, you can do the conversion on the client side. I don't think anybody would argue that MomentJS Timezone is the best library for this. Look over it and give it a shot.

http://momentjs.com/timezone/

Elaborating on DateTimeOffset

DateTimeOffset is another datatype like datetime except datetimeoffset adds an hour offset to determine the timezone. For instance, let's say you're in Central Timezone and you want to save the time 08:00 am. Well, in Datetimeoffset, it would be something like 08:00:00:00 -04:00 declaring that the offset was -4 (central timezone). This makes it easy because you don't have to do any math in your head when reading it and you really don't have to do any conversions (let MomentJS do it for you). When you read it, you will always know that "Oh, it was 08:00 am for whomever saved the time, and it looks like they saved it in Central timezone."

Upvotes: 1

Igor
Igor

Reputation: 62238

When sending DateTime instances to the server conversion conversion to UTC should happen as early as possible. In this case by the client and as your client is javascript you can use the method toUTCString. If you are using momentjs you can use utc.

When receiving DateTime instances from the server conversion conversion to local time should happen as late as possible. Make sure that persisted dates/retrieved dates are in UTC when you create them. Again, it is the client that should be converting them to local date time instance.

Finally send all datetime instances between client and server using ISO8601 format. Momentjs, javascript's date object, json.net all can do this. This ensures nothing is lost and no cultural specific bugs are introduced.

As to why it should be handled at the client is very simple, its easiest to do it there. Only the client truly knows its timezone, this is usually very difficult to "guess accurately" on the server side. The only reason not to do this is if you wanted to store a users timezone info with their profile but even this can get very tricky (what happens if the user travels or if they move location, etc).

As to how to persist you can use either a DateTime type or a DateTime with offset type (the true type names depend on the RDBMs you are using). Which one you choose should depend on if it is important to know the offset from utc at the moment it was saved. So far I have not had a need to do this but maybe it is important for you. It has no influence on the actual point in time as a DateTime should represent the UTC point in time and with offset should represent the local time with offset to get back to the UTC point in time.

Upvotes: 7

Related Questions