19

I am wondering if there are any good reasons to ever store time information in anything other that UTC (GMT)? I believe that this is a solid rule for all software engineering. The conversion to local time is merely a translation that happens at the UI layer for display purposes. I have also seen cases where the translatation is needed in order to implement an algorithm correctly (for handling midnight date changes, etc.).

Landon Kuhn
  • 76,451
  • 45
  • 104
  • 130
  • 1
    Say you're designing a server to manage certain real-world events. Say an event takes place "in Los Angeles, every Tuesday from 2PM to 3PM". How do you store that in UTC? – David Schwartz Apr 17 '12 at 07:44

7 Answers7

25

In general it I find it better to use UTC. Sometimes you might need a local time. Then I would rather go with UTC + timezone information.

In general times can be extremely tricky for repetitive events, and you should very carefully analyze the use cases.

Imagine a recurring meeting, every Tuesday at 9:00 am. If the DST changes, the meeting should still happen at (the new) 9:00am.

But no add to the meeting some guys in France. For them the meeting is at 6:00pm. And they change the DST by a different rule.

When you change the DST, they don't, so for a while (until France changes DST) someone should be "off": either your meeting will be at 10am that theirs will stay at 6pm, or keep yours at 9am and move theirs at 5pm. There is no other way, computers have nothing to do with it.

How will an application decide who should be "fixed"? Is it the group with most members? (1 guy in US vs 20 in France?) Or is it about the importance of the person? (what if the 1 guy in US is the CEO?)

How do you store that info? My best solution is to use UTC + one "master time zone" The users in the "master time zone" win (stay fixed).

Things can get pretty tricky, but in general I have found the UTC solves more problems than it introduces.

To clarify a (very valid :-) point from fjsj: by "master time zone" I mean the exact zone, including the info about DST active or not.

If you just store PT (Pacific Time), then it is not enough. PST (Pacific Standard Time) or PDT (Pacific Daylight Time) is.

Probably even better is not not think of recurring meetings as "a fixed point in time" expressed in seconds / milliseconds from the "epoch". Programming languages have (finally) started to adopt concepts from JodaTime.

Mihai Nita
  • 5,547
  • 27
  • 27
  • 1
    Please correct me if I'm wrong, but I think storing UTC + master time zone does not solve this problem of DST change. Practical example: 1 - You need to store the datetime "1 year from now in 9am NY time". you calculate if this in UTC and store it on your DB along with NY time zone. 2 - Before 1 year has passed, NY changes it's DST. That original date at 9am NY time is not the same date we have stored. – fjsj Apr 24 '17 at 23:46
  • 4 years after, sorry! But I think the information PST/PDT is not valid for future events, as the date where PST becomes PDT and vice-versa may change in the future. I don't know how it works specifically for US PT, but in some timezones the start of daylight saving time changes every year. For a future event, what you really need is saving "9am at America/Los Angeles". That will work regardless of LA being in PST and PDT. See: https://www.creativedeletion.com/2015/03/19/persisting_future_datetimes.html – fjsj Sep 24 '21 at 21:09
13

I'd say it's application-dependent. I work on space physics models of the Ionosphere & Magnetosphere. We work with magnetic local time, storing date & times as Modified Julian Days.

Pete
  • 10,310
  • 7
  • 53
  • 59
8

Alarms & scheduled tasks are sometimes stored in local time so that they aren't affected by Daylight Saving Time or timezone changes.

Roland Rabien
  • 8,750
  • 7
  • 50
  • 67
  • Are they /stored/ in local time or would a better way be to get the UTC & have a convertToLocalTime() member function? – Pete Jul 14 '09 at 20:34
  • 3
    @Pete: Think of my alarm clock: The alarm is set to 7am local time. When the clocks go back in winter, I do not want to be woken up at 6am. When I go on a business trip out west, I do not want to be woken up in the middle of the night just because it's 7am back home. – dave4420 Jul 14 '09 at 21:00
  • 2
    @Dave Yeah, so you would just change TIME_ZONE += n, so convertToLocalTime(currentUtc, TIME_ZONE, isDaylightSavingsTime) would return the local time (even though it's stored internally as UTC). – Pete Jul 14 '09 at 21:04
  • 4
    You could do all that but why? It doesn't gain you anything. – Roland Rabien Jul 14 '09 at 21:49
  • 3
    So for storing a time-of-day without any particular associated day, it can make sense to use local time. Good point. – Peter Cordes Dec 09 '09 at 05:16
5

UTC is a time-keeping standard that has the accuracy and precision of TAI, but with leap seconds added in at irregular intervals to allow it to closely track mean solar time (UT1).

If the system that you are working with cannot handle leap seconds, then the Bureau International des Poids et Mesures recommends that TAI be used instead of UTC.

See: http://tycho.usno.navy.mil/leapsec.html

Daniel Trebbien
  • 38,421
  • 18
  • 121
  • 193
  • 1
    Now you need more upvotes for this, I don't get why people think posix time is linear when it goes backwards once every few years – Pacerier Jan 13 '12 at 10:31
  • Pacerier: It goes backwards? Geez. I wasn't aware of that. I thought that it only leaped forward as a result of Earth's slowing rotation. – Daniel Trebbien Jan 13 '12 at 13:38
  • 3
    It had actually never leaped forward before in history (it's *possible* in the future) but had gone backwards on average once every 1.5 yrs. If we have a stopwatch which splits every half a second, the time goes like this: `58.0 58.5 59.0 59.5 00.0 00.5 00.0 00.5 01.0` http://en.wikipedia.org/wiki/Unix_time – Pacerier Jan 13 '12 at 13:58
2

Ever? I'm sure there are good reasons in some isolated cases. In general, though, storing UTC is much better than local time, so I would treat UTC as the default position unless there's some special consideration.

Tim Sylvester
  • 22,897
  • 2
  • 80
  • 94
2

In an embedded system you might well receive the time from a source in some sort of "ticks past epoch" form.

If the time is updated relatively frequently, and displayed relatively infrequently, then you might as well store it in the same way it's supplied to you and only convert it for display when needed.

In general, though, UTC is the way to go unless there are other considerations.

Vicky
  • 12,934
  • 4
  • 46
  • 54
0

When you are sure that only local time is going to be used.

FerranB
  • 35,683
  • 18
  • 66
  • 85
  • 5
    Even then, there is a good case to be made for using UTC if there is any kind of round-the-clock activity. Otherwise, handling the daylight-savings crossovers becomes a massive PITA. I speak from bitter experience. – Ken Keenan Jul 14 '09 at 20:30
  • Or if the time zone can be changed. A local times would have to be updated. – Landon Kuhn Jul 14 '09 at 20:50