237

As the subject asks; do UNIX timestamps change in each timezone?

For example, if I sent a request to another email the other side of the world saying, "Send out an email when the time is 1397484936", would the other server's timestamp be 12 hours behind my own?

ZygD
  • 22,092
  • 39
  • 79
  • 102
Ben Poulson
  • 3,368
  • 2
  • 17
  • 26
  • 13
    No, it's the number of seconds that have passed since a specific point in time. – Niklas B. Apr 14 '14 at 14:20
  • By definition "since UTC ..." is accepted. But the ambiguity of the question was, by what (until...) time zone is it calculated? that answer was same UTC. – Nabi K.A.Z. Apr 26 '22 at 16:36

7 Answers7

377

The definition of UNIX timestamp is time zone independent. The UNIX timestamp is the number of seconds (or milliseconds) elapsed since an absolute point in time, midnight of Jan 1 1970 in UTC time. (UTC is Greenwich Mean Time without Daylight Savings time adjustments.) Regardless of your time zone, the UNIX timestamp represents a moment that is the same everywhere. Of course you can convert back and forth to a local time zone representation (time 1397484936 is such-and-such local time in New York, or some other local time in Djakarta) if you want.

The article at http://en.wikipedia.org/wiki/Unix_time is pretty impressive if you'd like a longer read.

ZygD
  • 22,092
  • 39
  • 79
  • 102
RobP
  • 9,144
  • 3
  • 20
  • 33
  • 32
    In my other life I am a flight instructor. We use UTC (also known as "Zulu time") for takeoff and landing times, so that the *difference* between the times is an accurate measurement of the length of the flight, without having to consider what time zone the starting and ending airports are in. Indeed, I've taken flights that started in daylight savings time and ended after it, or vice versa! – RobP Apr 14 '14 at 14:28
  • 30
    +1 to this answer. To add an idea that might help clarify: the timestamp itself is not UTC, the timestamp is a number of (milli)seconds passed from a reference point in time. The reference point for the Unix timestamp (the Unix epoch) is the one that's UTC: 00:00:00 UTC 1970.01.01 – Sandman Apr 19 '14 at 19:44
  • 11
    Building further off of @Sandman 's response, 1397484936 seconds from the start is just that, 1397484936 seconds. Without getting into other science, 1397484936 seconds have elapsed at that point everywhere in the world. When those 1397484936 seconds have elapsed it might be 4PM:16:00 in New York, 9PM/21:00 in London , which is local time*zones* – conrad10781 May 04 '17 at 00:32
  • 1
    @RobP Thats not true. UNIX is not timezone independent, you said it yourself `in UTC time`. There are two offsets, a `raw offset` and `DST offset`. For example `America/New_York` raw offset is `-18000`, and DST offset is `3600`, so from any UNIX timestamp you have to do the math `UNIX + offset + dstOffset` in order to get the New York timestamp. – Max S. Mar 30 '19 at 20:15
  • @Max I might be wrong, but I think that RobP is saying that the timestamp value will be the same regardless of your actual location since it measures seconds elapsed from an absolute point in time. If you want the actual datetime (e.g. 1 Jan 2020 09:10:30 New York) -- a different concept from timestamps, then you need the 'raw offset' and 'DST offset' to calculate via your equation. However, it remains that the timestamp is the same (i.e. it's `UNIX` in your equation: 'New York timestamp' = 'UNIX' = 'any zone timestamp'). – krismath Aug 19 '20 at 04:20
  • 4
    @Max I think you actually miss the point as soon as you say "New York timestamp" - there is such a thing as *New York time* but a *timestamp* is locale and timezone independent. This allows you to easily compare two timestamps without any arithmetic, to see which is earlier and which is later. – RobP Aug 20 '20 at 15:35
25

Unix time is defined as the number of seconds that have elapsed since 00:00:00 Coordinated Universal Time (UTC), Thursday, 1 January 1970. So the answer is no

Harry
  • 1,362
  • 12
  • 19
  • By definition "since UTC ..." is accepted. But the ambiguity of the question was, by what (until...) time zone is it calculated? that answer was same UTC. – Nabi K.A.Z. Apr 26 '22 at 15:57
11

Unix timestamps do not change accross timezones, they are created for the purpose of having a standard time across globe.

NOTE:- Timestamps are calculated on the basis of current time in the computer thus do not rely on them until and unless you are very sure about the time settings in the participating machines.

humble_wolf
  • 1,497
  • 19
  • 26
8

IF both computers are set up correctly with their clocks set for the correct timezone and UTC values, they should return the same value.

Of course that's a big IF. There's almost certain to be a difference of at least a second, more often minutes between the time reported by two computers. And many computers are set up to have incorrect timezone settings, and will report their local time when asked a timestamp rather than UTC.

And in that lies the difference between theory and practice. In theory it's all the same, in practice you should not rely on it.

ZygD
  • 22,092
  • 39
  • 79
  • 102
jwenting
  • 5,505
  • 2
  • 25
  • 30
8

Someone stated that "UTC is Greenwich Mean Time without Daylight Savings time adjustments." This is simply untrue. GMT does not have Dayllight Savings Time. GMT is measured in Greenwich, England (at the Naval Obeservatory) [0 longitude, but not 0 lattitude]. UTC is measured at the equator [0 longitude and 0 lattitude - which happens to lie in the ocean off the cost of Africa].

What difference does it make? It doesn't make a difference in terms of "what time of day is it?" It does, however, make a difference in terms of calculating a year. Now you'd think a year would be measured based upon the location of the center (the core) of the earth, right? When the earth's core is back in the same location it was ~365 days ago, it has been a year. It isn't measured that way. It is measured by a specific location on the earth getting back to the same location (relative to the sun) that it was ~365 days ago. But the period of a day and a year don't divide evenly. Once the earth is back to about where it was a year ago, the earth isn't facing the same direction it was last year, so that spot on the earth isn't facing the same direction it was a year ago. Being further north, Greenwich isn't going to get back to the same spot (relative to the sun) that it was last year at the same time that 0 Lat / 0 Long is. So if you base the definition on Greenwith vs. 0/0, you get a, albeit slightly, different answer to the question "how many days are in a year". To put it another way, when a given spot on the earth gets back to where it was a year ago (relative to the Sun), the core of the earth isn't in the same spot it was a year ago, so what spot you pick matters because the core of the earth is going to be in a different spot (relative to the sun) than it was one year ago, if you pick a different spot on the earth.

Neither UTC nor GMT have daylight savings time. Europe/London time, the timezone that Greenwich resides in, does. But GMT does not. GMT is, what Americans would call a "Standard Time" - i.e. without DST.

Getting back to the question, Epoch time doesn't technically have a timezone. It is based on a particular point in time, which just so happens to line up to an "even" UTC time (at the exact beginning of a year and a decade, etc.). If that concept doesn't fit well in your brain, and if it helps to think of Epoch time as being in UTC, go right ahead. You're in good company and in the grand scheme of things, it really doesn't matter. You ever see those law suits where somoene is awarded $1. It's kind of a "you're right, but it doesn't really matter" type of verdict. If someone sued you for saying Epoch time is in the UTC timezone, they would win $1. That wouldn't buy them a cup of coffee at any Starbucks in any timezone on the planet.

Damocles
  • 89
  • 1
  • 1
  • 1
    'So if you base the definition on Greenwich vs. 0/0, you get a, albeit slightly, different answer to the question "how many days are in a year".' How did you come up with that idea? If it was true, the difference would add up, and after a certain number of years, it would be December in Greenwich and January at 0/0. (Or vice versa.) Impossible. Am I missing something? – jcsahnwaldt Reinstate Monica Apr 23 '22 at 03:17
1

No, epoch timestamp should not change, because it has a fixed timezone which is UTC.

If you want to use a time object in other time zone, just look it up in libraries of the language you use, but do NOT try to add/substract a couple of hours from epoch timestamp and assume it's in another time zone, which will make things very confusing to other people, especially when you expose it in your API.

If you use C++, I recommend this library. I heard it will soon be added into standard library.

For all, I understand sometimes time object is hard to deal with and it looks easier to add/substruct on epoch timestamp. Please don't do it and do not persuade others to do it. A time object is much easier once you get used to it and can take care of time zone conversion easily without messing up with historical time zone changes due to politics/law etc...

frank
  • 178
  • 2
  • 7
0

I am just sharing my thoughts on this and please correct me if I am wrong.

Only a timestamp is not enough to convert any timestamp to DateTime of a specific time zone. We need timestamp && timezone to convert the timestamp to the datetime of desired timezone.

  1. Convert timestamp to local datetime.
  2. Get UTC time from Local DateTime time the time zone (Check your server timezone setup where this timestamp data was generated)
  3. Once you get the UTC time, you can convert it to any date time of a specific time zone. For example, Sydney is 10 hours ahead of UTC time. If the server time zone = UTC, just add/subtract those hours (don't forget the convert those hours into seconds) from your timestamp data according to the desired timezone.

So basically you need to know both the timestamp && time zone information to convert it to the DateTime of the desired timezone.

kta
  • 19,412
  • 7
  • 65
  • 47