UNIX Time and UNIX Timestamps

A recent comment on my story about converting UNIX timestamps to Oracle dates prompted me to do a little extra digging on UNIX time.

UNIX time is a standard system used not only in UNIX but in many other modern computer systems. Instead of being divided into years, months, hours, minutes, etc. UNIX time is simply a number which represents the number of seconds which have passed since midnight Coordinated Universal time (UTC, the same time zone as Greenwich Mean Time, sometimes referred to as Zulu time), January 1, 1970. This date is often referred to as the UNIX epoch.

Sound like a lot of seconds? It is. At the time of this writing it has been 1,145,404,660 since the UNIX epoch, but since people like to think of dates the old fashioned way, in years, months, days, hours, minutes and seconds the computer is almost always nice enough to convert the UNIX time into the familiar date and time format, and to your local time zone.

One of the strengths of UNIX time is that when it is recorded (a point in UNIX time is typically referred to as a UNIX timestamp) it is always relative to Greenwich Mean Time. That means UNIX timestamps can be easily converted to different time zones with no ambiguity.

For all the gruesome details on UNIX time, Wikipedia has a typically thorough article on the topic.

While there are several sites on the web to convert a UNIX timestamp to human readable format and vice-verse be careful. Many sites will do the conversion based on their time zone. 4WebHelp.net provides a great page for converting both ways.

In contrast to UNIX time, Oracle Databases record time in a more traditional year, month, day, hour, minute, second manner. In order to convert Oracle dates to a different time zone you need to know what time zone the date was originally recorded in. Only recently has Oracle introduced a time datatype with a time zone attribute.

unix, time, timestamp, time zone, date, oracle, database, solaris, linux

3 thoughts on “UNIX Time and UNIX Timestamps”

  1. I have a question for anyone, regarding the use of Unix Epoc time as a “guaranteed, unique” record ID. I manage a system in a non-Unix environment that utilizes a similar “time stamp”, using an internal 5-digit date, concatenated with seconds-since-midnight. If I wish to use this stamp as a record ID, I have to expect that other requests are being made for the time-date stamp, and may find an alpha character appended (1411035660a). I have actual examples of this scenario where the letter “p” has been appended, meaning 15 other applications were asking for time-date stamp, simultaneously. At the speed of today’s processors, this can be expected. In another test, I wrote the time-date, 10-digit stamp to a file with 56,000+ records, all in 7 seconds. Meaning, 8000+ records got the same time-date stam, except for an appendage of 3-character alpha (aaa – zzz). This being said, is there a similar problem that I could expect from using the Unix Epoch 10-digit stamp, where I want this to be a “unique” identifier? In other words, if multiple processes, per second, ask for Unix Epoch, will they all get the same response?

    I hope I have explained my problem clearly. Thanks, in advance, for any responses.

    Jim Cronin

  2. Jim,

    Yes, if multiple processes ask for the UNIX timestamp durring the same second they will get the exact same timestamp. Because of this it is almost always a bad idea to use a date or timestamp for a primary key.

    If this is a database you will want to set up an auto-increment in one way or another. The methods vary by database, but if it’s Oracle I have directions posted here:


    Hope this helps.

  3. I wrote up a handy utility for developers that need to convert unix timestamps frequently: http://www.unixstamp.com

    It’s a wrapper for the strtotime() function so you can convert pretty much anything:

    Hope you find it useful!

Leave a Reply

Your email address will not be published. Required fields are marked *