If you are a programmer, and you have dealt with dates, you likely have heard the terms Unix epoch and Unix timestamps. The question is have you faced difficulties in dealing with timestamps for different time zones? Have you faced difficulties in grasping the whole idea of timestamps?
I started using these words/values without knowing their real meaning. My limited knowledge was enough back then as my transactions were simply saving and reading timestamps and, as a Java programmer, I had Date API for the rescue in simple date arithmetic.
Problems started when I started manipulating the dates in different time zones. I saved a timestamp to my server from my browser(I am a web developer) and then fetched the data after changing the time zone ( I was unit testing the system for different time zones) of my browser. Interestingly, the value the browser got back from the server was a different than the one I saved earlier….. A lot of debugging revealed that there was nothing wrong with the save or fetch of my timestamps from the server. So the problem must be with the way I am treating these timestamp values in my browser. I started reading about timestamps and unix epoch. I found some really interesting ways in which I was messing up my timestamps. I will share what I learned here.
We will go through the following sections to understand the relationship between timestamps, timezones and textual representation of a timestamp.
- Unix epoch
- Timestamps and a thought experiment to understand it
- What I did wrong / What I didn’t know
- Wrapping it up
Lets get started
1. Unix epoch
You have heard this term before. It is the exact moment when it was Thursday January 01, 1970 05:30:00 (am) in India(timezone = Asia/Kolkata). Wondering why I used India instead of Greenwich? 2 reasons.
- Unix epoch is a moment in time that is independent of the timezone
- I want to express this idea as simple as possible
Lets take the first point. Unix epoch is a specific point in time. At that point in time, in India it was Thursday January 01, 1970 05:30:00 (am) (IST, UTC+5:30), in Greenwich it was Thursday January 01, 1970 00:00:00 (am) (UTC), in Japan it was Thursday January 01, 1970 09:00:00 (am) (JST, UTC+9:00) and so on. If you look closely, you can see that, they all are the same! The same moment in time! Its just the human understandable textual representation changes with the timezone. That moment, in India people called it Thursday January 01, 1970 05:30:00 (am) (IST, UTC+5:30), in Greenwich people called it Thursday January 01, 1970 00:00:00 (am) (UTC), in Japan people called it Thursday January 01, 1970 09:00:00 (am) (JST, UTC+9:00) and so on.
2. Timestamps and a thought experiment to understand it
Unix time is a system for describing a point in time. It is the number of seconds that have elapsed since the Unix epoch, minus leap seconds; the Unix epoch is 00:00:00 UTC on 1 January 1970. Leap seconds are ignored, with a leap second having the same Unix time as the second before it, and every day is treated as if it contains exactly 86400 seconds
Unix time is a single signed number that increments every second, which makes it easier for computers to store and manipulate than conventional date systems. Interpreter programs can then convert it to a human-readable format.
Wikipedia
This is the definition of Unix time according to Wikipedia. Not a simple one for beginners I think. Lets understand it with a thought experiment.
Imagine that you live in India, and you have friends in Japan and Greenwich. You, with your friends decides to do an experiment at the Unix epoch moment. The experiment is as follows. You will call(a group call) your friends on Unix epoch and ask them to write down the time displayed on their clock. You and your friends know that, that moment is the origin coordinate of the timestamp and the timestamp value is zero. But you will write down the time Thursday January 01, 1970 05:30:00 (am). Your Greenwich friend will write down the time Thursday January 01, 1970 00:00:00 (am). Your Japan friend will write down the time Thursday January 01, 1970 09:00:00 (am). So, even though the timestamp value was zero for all these timezones, the textual representation for that moment/timestamp changed with timezone. Now, read the paragraph given above again.
The thought experiment was done on Unix epoch hence the timestamp was zero. But the same applies to all timestamps. It doesn’t matter if it is the epoch moment or 10000 seconds past the epoch. You and your friends will note down the same timestamp(10000 now) and the moment’s different textual representations in their respective timezone!
Similarly, time in millis is the number of milli-seconds past the Unix epoch. It too is independent of the timezone.(Do the thought experiment by yourself for milliseconds instead of seconds like we did before)
3. What I did wrong / What I didn’t know
At the beginning of this article, I quoted a problem I faced with timestamps and time zones. What I did not understand while manipulating/displaying date-times back then was that the same timestamp has different textual representation for different timezone. This was a big revelation for me. A small piece of knowledge that helped/and will help me to design, develop and debug systems dealing with timestamps with even more ease.
4. Wrapping it up
I would like to wind this article up with 2 more points
- Read more on this topic. https://en.wikipedia.org/wiki/Unix_time will be a good start
- It is important to know the concepts. But its also important to use a well tested library like Date time API in Java 8, moment api for JavaScript etc. when dealing with date-times; if you are not trying to create one such library. Because there are a lot more to date and time like leap seconds, daylight saving time etc. and these calculations and are out of the scope of this article.
Hope you got a better idea of Unix epoch and timestamps now.
🙂
BROKEN CODE 