CODEWITHSUNDEEP
datetimelanguage-agnosticutc
sennett
sennett

Reputation: 8444

Why should I use UTC?

Our app currently uses a local time rather than UTC. I know that it's important to use UTC, but cannot for the life of me remember why.

Assuming that the DateTimes are stored with an offset, when comparing a local time to a UTC time, or with another time with a different timezone, surely any library worth using will know about the different timezones and mutate the two objects into something that can be compared?

As long as the offset is passed around with the DateTime (which it will be using objects rather than strings, say), I do not see why it matters. Why should I deal with 2014-09-01T13:44:13+00:00 rather than 2014-09-01T14:44:13+01:00? In fact, storing as UTC looses the offset information (the local time when the time was declared).

What am I missing here?

Context: We are having limit, off-by-one style errors, and I thought 'aha: move all the things to UTC' but then realised that I am just going through the code converting a bunch of DateTime objects to use a UTC timezone, and this struck me as a waste of time.

Upvotes: 21

Views: 19614

Answers (3)

tomsoft
tomsoft

Reputation: 4577

I think the best is to store DateTIme+Offset

The point is you must always store DateTime either in UTC or with in offset, but never store DateTime "local centric", or without the offset. In other words:

Best! DateTime+Offset

2014-09-03 11:36:07 EDT -04:00

Good UTC:

2014-09-03 15:36:07 UTC

Veryyyyy bad: DateTime no offset

2014-09-03 11:36:07

For instance, this could happens if you don't really care of time zone and at the end the previous time could happen to be stored as:

2014-09-03 11:36:07 UTC

Now, depending on your language framework, it might happens that you might need to convert your DateTime/Offset in something different, but my advice is to store always as the first form....

Upvotes: 2

Markus Malkusch
Markus Malkusch

Reputation: 7878

Your use case allows storing a local time with an offset. IMO there is no need to store in UTC, as you can always translate the point in time into any other local time. In fact it gives you even more, as you have additionally the information about the local time.

Technically there is an advantage in storing the date as UTC and the offset separately: You can sort on a string, which gives you an advantage in e.g. DBS which don't support date fields with offsets properly (e.g. MySQL).

If you consider systems which don't allow storing an offset, the actors will have to agree on a common timezone. UTC seems to be a very stable candidate with good timezone translation support.

One example for this is Exif where you can only store a local date without any timezone information. Another example is the hardware clock in a multi OS computer. If the actors don't agree on a common timezone, you will get headaches (Linux & Windows can get funny during DST switch).

Upvotes: 11

Nick Zimmerman
Nick Zimmerman

Reputation: 1531

There are two reasons that I store time as UTC.

First, is that with global users of some of the applications I work on, local time varies per user, so local time for a user that entered the data may not be local time for a user viewing the data later.

Second, timezones change. They are subject to the whims of governments. What is UTC +5 today could be UTC +6 tomorrow just because some government says so, which would then make the local time + offset different than what was stored. You can always figure out the correct local time, but I just view it as more work than just converting UTC to local.

Those are the best reasons that I am aware of for using UTC, but I am sure there are others I haven't thought of.

Upvotes: 16

Related Questions