Epoch time

What Is Unix Time and When Was the Unix Epoch?

Why does Unix have its own concept of time? What is the epoch and what’s the Y2038 problem?

Unix time is a means of representing a specific date and time, used by Linux, macOS, and many other interoperable systems. It’s so widespread, that you’re probably using it without being aware of it. Once you understand Unix time, though, you’ll spot it in many contexts. Several tools can help you to work with Unix time.

What Is the Purpose of Unix Time?

Unix time is a count of total seconds since a fixed time and date. It’s a date/time (or timestamp) format that looks different from the human-readable dates and times we’re used to. This is purely for efficiency reasons. It takes a lot less space to store a single number representing seconds than it does to store separate values for the year, month, hour, etc.

Of course, in modern terms, the space difference isn’t all that much at all. But consider that Unix originated in the late 1960s when available storage was far smaller. Timestamps are also used a lot, so their storage adds up. For example, every file has three timestamps associated with it.

The format is pretty much impossible to translate in your head unless you’re a mathematical genius. But it still has some advantages over more readable alternatives such as Wed, 21 Oct 2015 07:28:00 GMT. You can order two Unix timestamps very easily, at a glance. It’s also usually quicker to work out the difference between two timestamps. This is particularly true for dates close together, such as on adjacent days.

About the Epoch

So, Unix time is a total count of seconds since a specific point in time. But what is that point in time? It’s 00:00:00 UTC on 1st January 1970. This is often referred to as the Unix Epoch. Programmers chose this date for the epoch out of convenience since it was the closest round date when they invented Unix time.

You may well have seen this date when something has gone wrong. It’s clearly a bug, but one that looks very strange when it results in a date from before the time many of us were born! It’s completely understandable, though, when you know about Unix time. If any system is trying to display a timestamp that doesn’t have any value, it will often translate to 0 and result in the exact epoch date.

The Unix Time Data Format

Strictly speaking, there isn’t one. The original data type was a 32-bit integer, and this often remains the case, even in much more powerful systems.

This data type allows the value to store a total of 2^32 seconds, which is just over 136 years. This value is typically signed, meaning that it can be negative or positive. So, it usually represents 68 years on either side of the epoch i.e. 1902-2038.

This is still a limited period, of course. But the primary use of the timestamp format was for concepts such as file modification. The need was very much to represent time close to the present, rather than ancient history or far into the future. Even for applications such as calendars, there is rarely a need to represent dates more than a few decades into the future.

But that doesn’t mean this limited time span is without problems…

The Year 2038 Problem

The Y2K Bug (one of the worst programming mistakes in history) affected computer systems that stored years as two-digit values. When the year 2000 came around, such systems treated it as if it were 1900. In the event, this wasn’t as catastrophic as feared, mainly because many people spent a lot of time and effort in advance, preparing for it.

If you were paying attention in the previous section, you might have spotted a similar problem that could affect Unix time. Well, Unix time does have a data problem of its own: the Y2k38 problem. (It’s often referred to as a problem, not a bug; maybe we’ve become more optimistic since the year 2000!) When Unix time literally runs out in 2038, systems will treat new dates either as 1902 or 1970. Or possibly they’ll just fail altogether.

At least this problem won’t hit us at the stroke of midnight on New Year’s Eve. The final second of 32-bit Unix time will fall on the 19th of March. In the eventuality, we will likely upgrade most systems by 2038 or they’ll be obsolete by then anyway.

Some Useful Timestamp Resources

The Epoch Converter site is possibly the most comprehensive timestamp converter available. It begins by displaying the current Unix time—in real-time—and adds almost every imaginable feature on top of that. Its main use is for converting between timestamps and human-readable dates, in both directions.

Dan’s Tools is a huge collection of useful web apps, one of which is a timestamp converter. It’s more basic, but has a very clean presentation and is easy to use.

Time.is presents another, even more minimalistic look. It shows time in a number of formats, including Unix time. It includes the current time in its page title which is useful.

Using Unix Time With Command Line Tools

On Linux and macOS, the date program is the core utility for dealing with date/time, including Unix timestamps. Called without any arguments, it returns the current date/time in a human-readable format:

If you need the current date/time in Unix time, use the +%s argument:

You can convert from a human-readable date into a timestamp using the -d flag if your version of date supports it. Most Linux versions should, by default:

On macOS, date is a different program, which requires a different set of flags:

Going in the other direction, you can convert from a Unix timestamp using the -r flag:

Some other programs use the %s format to deal with Unix time. For example, if you want to show the modification date of a file in Unix time, with the Linux version of ls, you can use the following:

How to Use Unix Time in Programming Languages

PHP has the time() function which returns the current Unix timestamp. Its date() function takes a timestamp as its second argument:

JavaScript approaches things in an interesting way. It has a Date.now() method to get the number of milliseconds since the Unix epoch. Of course, you can divide this by 1,000 and round the result to give the equivalent Unix time in seconds:

Understanding Unix Time

Unix time is a simple concept that crops up in many places. Once you understand it, you might find it quite useful, when calculating time differences, for example. You can also recognise when it may be the cause of certain bugs.

Concepts such as the epoch and timestamps are an important part of getting started with Linux. To find out more about essentials such as ls, check out our guide to basic Linux commands.


9 Basic Commands to Get You Started With Linux

Want to gain familiarity with Linux? Start with these basic Linux commands to learn standard computing tasks.

Read Next

About The Author
Bobby Jack (61 Articles Published)

Bobby is a technology enthusiast who worked as a software developer for most of two decades. He’s passionate about gaming, working as Reviews Editor at Switch Player Magazine, and is immersed in all aspects of online publishing & web development.

More From Bobby Jack

Subscribe to our newsletter

Join our newsletter for tech tips, reviews, free ebooks, and exclusive deals!

Click here to subscribe

Sours: https://www.makeuseof.com/what-is-unix-time-and-when-was-the-unix-epoch/

Java Service to convert Epoch Time to Simple Date Time Format

What is epoch time?

The Unix epoch (or Unix time or POSIX time or Unix timestamp) is the number of seconds that have elapsed since January 1, 1970 (midnight UTC/GMT), not counting leap seconds (in ISO 8601: 1970-01-01T00:00:00Z). Literally speaking the epoch is Unix time 0 (midnight 1/1/1970), but 'epoch' is often used as a synonym for Unix time. Some systems store epoch dates as a signed 32-bit integer, which might cause problems on January 19, 2038 (known as the Year 2038 problem or Y2038). The converter on this page converts timestamps in seconds (10-digit), milliseconds (13-digit) and microseconds (16-digit) to readable dates.

Human-readable time Seconds
1 hour3600 seconds
1 day86400 seconds
1 week604800 seconds
1 month (30.44 days) 2629743 seconds
1 year (365.24 days)  31556926 seconds

More details on https://www.epochconverter.com/

Here is the java utility service to convert Epoch Time to Simple Date Time Format. Create a java service "GetDateTimeByEpoch" and define the below input and output, copy-paste the code as provided below, add the required imports:

Input: epochTime (String)

Output: dateTimeStamp (String)

Note, if the input epochTime=1563370941000 (assuming that this timestamp is in milliseconds), then you might have to stripe the trailing zeros by dividing by 1000.

Sours: https://tech.forums.softwareag.com/t/java-service-to-convert-epoch-time-to-simple-date-time-format/237276
  1. 32 birthday invitation
  2. Tricare dental program
  3. Rare elvis pictures

What is Unix time?

Unix time is a system for representing a point in time. It is the number of seconds that have elapsed since January 1st, 1970 00:00:00 UTC.


Unix is an operating system originally developed in the 1960s.  Unix time is a way of representing a timestamp by representing the time as the number of seconds since January 1st, 1970 at 00:00:00 UTC.  One of the primary benefits of using Unix time is that it can be represented as an integer making it easier to parse and use across different systems. 

Narrative's Data Streaming Platform defaults to using Unix time (in milliseconds) for all timestamp fields.  

Unix Epoch

January 1st, 1970 at 00:00:00 UTC is referred to as the Unix epoch.   Early Unix engineers picked that date arbitrarily because they needed to set a uniform date for the start of time, and New Year's Day, 1970, seemed most convenient.


Date / TimeUnix Time
January 1st, 1970 00:00:000
June 6th, 1983 00:00:00423792000
June 6th, 1983 16:00:00423849600
September 9, 2001 1:46:401000000000
July 20th, 1969 20:17:40-14182940



Year 2038 Problem

The year 2038 problem is related to Unix time because times after 03:14:07 UTC on 19 January 2038 will require computers to store the value as greater than 32-bits.  Systems built assuming that the time would always fit withing 32-bits will result in undefined behavior potentially causing those systems to crash, become unusable, or create other undesired effects. The problem is similar to the Y2K problem which arose when developers assumed that years could be stored in two digits instead of four. 

Leap Seconds

Leap seconds are ignored in Unix time.  Leap seconds have the same Unix time as the second before it.  The underlying assumption is that each day has exactly 86,400 seconds.  Because of this Unix time is not a true representation of UTC.

Pre-1970 Timestamps

The Unix epoch is at the beginning of 1970 meaning that any timestamp prior to 1970 needs to be represented as a negative number representing the number of seconds until January 1st, 1970 00:00:00 UTC.


If the timestamp needs to represent a time that is smaller than one second a variation of Unix time needs to be employed.

Unix Time w/Decimals

One way to represent timestamps with greater precision than a single second is instead of representing time using whole numbers, instead use decimals to represent fractions of a second.

Unix Time in Milliseconds

Another option is to represent timestamps using the number of milliseconds since the Unix epoch instead of the number of seconds.  This is the methodology adopted by Narrative.

Additional Resources

Sours: https://kb.narrative.io/what-is-unix-time

Unix time

For the Wikipedia time function, or #time, see Help:Time function.

System for identifying instants in time for computers

Current Unix time
1634833549 (update)

Unix time passed 1000000000seconds on 2001-09-09T01:46:40Z. It was celebrated in Copenhagen, Denmark at a party held by DKUUG(at 03:46:40 local time).

Unix time (also known as Epoch time, Posix time,[1]seconds since the Epoch,[2] or UNIX Epoch time[3]) is a system for describing a point in time. It is the number of seconds that have elapsed since the Unix epoch, excluding leap seconds. The Unix epoch is 00:00:00 UTC on 1 January 1970 (an arbitrary date). Unix time is nonlinear with a leap second having the same Unix time as the second before it (or after it, implementation dependent), so that every day is treated as if it contains exactly 86400 seconds,[2] with no seconds added to or subtracted from the day as a result of positive or negative leap seconds. Due to this treatment of leap seconds, Unix time is not a true representation of UTC.

Unix time is widely used in operating systems and file formats. In Unix-like operating systems, is a command which will print or set the current time; by default, it prints or sets the time in the system time zone, but with the flag, it prints or sets the time in UTC and, with the environment variable set to refer to a particular time zone, prints or sets the time in that time zone.[4]


Two layers of encoding make up Unix time. The first layer encodes a point in time as a scalarreal number which represents the number of seconds that have passed since 00:00:00 UTC Thursday, 1 January 1970.[5] The second layer encodes that number as a sequence of bits or decimal digits.

As is standard with UTC, this article labels days using the Gregorian calendar, and counts times within each day in hours, minutes, and seconds. Some of the examples also show International Atomic Time (TAI), another time scheme which uses the same seconds and is displayed in the same format as UTC, but in which every day is exactly 86400 seconds long, gradually losing synchronization with the Earth's rotation at a rate of roughly one second per year.

Encoding time as a number[edit]

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.

The Unix epoch is the time 00:00:00 UTC on 1 January 1970.[2] There is a problem with this definition, in that UTC did not exist in its current form until 1972; this issue is discussed below. For brevity, the remainder of this section uses ISO 8601 date and time format, in which the Unix epoch is 1970-01-01T00:00:00Z.

The Unix time number is zero at the Unix epoch, and increases by exactly 86400 per day since the epoch. Thus 2004-09-16T00:00:00Z, 12677 days after the epoch, is represented by the Unix time number 12677 × 86400 = 1095292800. This can be extended backwards from the epoch too, using negative numbers; thus 1957-10-04T00:00:00Z, 4472 days before the epoch, is represented by the Unix time number −4472 × 86400 = −386380800. This applies within days as well; the time number at any given time of a day is the number of seconds that has passed since the midnight starting that day added to the time number of that midnight.

Unix time is sometimes, mistakenly, referred to as Epoch time, because Unix time is based on an epoch, and because of a common misunderstanding that the Unix epoch is the only epoch (often called "the Epoch" [2]).[6][7][8]

Leap seconds[edit]

The above scheme means that on a normal UTC day, which has a duration of 86400 seconds, the Unix time number changes in a continuous manner across midnight. For example, at the end of the day used in the examples above, the time representations progress as follows:

TAI (17 September 2004) UTC (16 to 17 September 2004) Unix time
2004-09-17T00:00:30.75 2004-09-16T23:59:58.75 1095379198.75
2004-09-17T00:00:31.00 2004-09-16T23:59:59.00 1095379199.00
2004-09-17T00:00:31.25 2004-09-16T23:59:59.25 1095379199.25
2004-09-17T00:00:31.50 2004-09-16T23:59:59.50 1095379199.50
2004-09-17T00:00:31.75 2004-09-16T23:59:59.75 1095379199.75
2004-09-17T00:00:32.00 2004-09-17T00:00:00.00 1095379200.00
2004-09-17T00:00:32.25 2004-09-17T00:00:00.25 1095379200.25
2004-09-17T00:00:32.50 2004-09-17T00:00:00.50 1095379200.50
2004-09-17T00:00:32.75 2004-09-17T00:00:00.75 1095379200.75
2004-09-17T00:00:33.00 2004-09-17T00:00:01.00 1095379201.00
2004-09-17T00:00:33.25 2004-09-17T00:00:01.25 1095379201.25

When a leap second occurs, the UTC day is not exactly 86400 seconds long and the Unix time number (which always increases by exactly 86400 each day) experiences a discontinuity. Leap seconds may be positive or negative. No negative leap second has ever been declared, but if one were to be, then at the end of a day with a negative leap second, the Unix time number would jump up by 1 to the start of the next day. During a positive leap second at the end of a day, which occurs about every year and a half on average, the Unix time number increases continuously into the next day during the leap second and then at the end of the leap second jumps back by 1 (returning to the start of the next day). For example, this is what happened on strictly conforming POSIX.1 systems at the end of 1998:

TAI (1 January 1999) UTC (31 December 1998 to 1 January 1999) Unix time
1999-01-01T00:00:29.75 1998-12-31T23:59:58.75 915148798.75
1999-01-01T00:00:30.00 1998-12-31T23:59:59.00 915148799.00
1999-01-01T00:00:30.25 1998-12-31T23:59:59.25 915148799.25
1999-01-01T00:00:30.50 1998-12-31T23:59:59.50 915148799.50
1999-01-01T00:00:30.75 1998-12-31T23:59:59.75 915148799.75
1999-01-01T00:00:31.00 1998-12-31T23:59:60.00 915148800.00
1999-01-01T00:00:31.25 1998-12-31T23:59:60.25 915148800.25
1999-01-01T00:00:31.50 1998-12-31T23:59:60.50 915148800.50
1999-01-01T00:00:31.75 1998-12-31T23:59:60.75 915148800.75
1999-01-01T00:00:32.00 1999-01-01T00:00:00.00 915148800.00
1999-01-01T00:00:32.25 1999-01-01T00:00:00.25 915148800.25
1999-01-01T00:00:32.50 1999-01-01T00:00:00.50 915148800.50
1999-01-01T00:00:32.75 1999-01-01T00:00:00.75 915148800.75
1999-01-01T00:00:33.00 1999-01-01T00:00:01.00 915148801.00
1999-01-01T00:00:33.25 1999-01-01T00:00:01.25 915148801.25

Unix time numbers are repeated in the second immediately following a positive leap second. The Unix time number 1483142400 is thus ambiguous: it can refer either to start of the leap second (2016-12-31 23:59:60) or the end of it, one second later (2017-01-01 00:00:00). In the theoretical case when a negative leap second occurs, no ambiguity is caused, but instead there is a range of Unix time numbers that do not refer to any point in UTC time at all.

A Unix clock is often implemented with a different type of positive leap second handling associated with the Network Time Protocol (NTP). This yields a system that does not conform to the POSIX standard. See the section below concerning NTP for details.

When dealing with periods that do not encompass a UTC leap second, the difference between two Unix time numbers is equal to the duration in seconds of the period between the corresponding points in time. This is a common computational technique. However, where leap seconds occur, such calculations give the wrong answer. In applications where this level of accuracy is required, it is necessary to consult a table of leap seconds when dealing with Unix times, and it is often preferable to use a different time encoding that does not suffer from this problem.

A Unix time number is easily converted back into a UTC time by taking the quotient and modulus of the Unix time number, modulo 86400. The quotient is the number of days since the epoch, and the modulus is the number of seconds since midnight UTC on that day. If given a Unix time number that is ambiguous due to a positive leap second, this algorithm interprets it as the time just after midnight. It never generates a time that is during a leap second. If given a Unix time number that is invalid due to a negative leap second, it generates an equally invalid UTC time. If these conditions are significant, it is necessary to consult a table of leap seconds to detect them.

Non-synchronous Network Time Protocol-based variant[edit]

Commonly a Mills-style Unix clock is implemented with leap second handling not synchronous with the change of the Unix time number. The time number initially decreases where a leap should have occurred, and then it leaps to the correct time 1 second after the leap. This makes implementation easier, and is described by Mills' paper.[9] This is what happens across a positive leap second:

TAI (1 January 1999) UTC (31 December 1998 to 1 January 1999) State Unix clock
1999-01-01T00:00:29.75 1998-12-31T23:59:58.75 TIME_INS 915148798.75
1999-01-01T00:00:30.00 1998-12-31T23:59:59.00 TIME_INS 915148799.00
1999-01-01T00:00:30.25 1998-12-31T23:59:59.25 TIME_INS 915148799.25
1999-01-01T00:00:30.50 1998-12-31T23:59:59.50 TIME_INS 915148799.50
1999-01-01T00:00:30.75 1998-12-31T23:59:59.75 TIME_INS 915148799.75
1999-01-01T00:00:31.00 1998-12-31T23:59:60.00 TIME_INS 915148800.00
1999-01-01T00:00:31.25 1998-12-31T23:59:60.25 TIME_OOP 915148799.25
1999-01-01T00:00:31.50 1998-12-31T23:59:60.50 TIME_OOP 915148799.50
1999-01-01T00:00:31.75 1998-12-31T23:59:60.75 TIME_OOP 915148799.75
1999-01-01T00:00:32.00 1999-01-01T00:00:00.00 TIME_OOP 915148800.00
1999-01-01T00:00:32.25 1999-01-01T00:00:00.25 TIME_WAIT 915148800.25
1999-01-01T00:00:32.50 1999-01-01T00:00:00.50 TIME_WAIT 915148800.50
1999-01-01T00:00:32.75 1999-01-01T00:00:00.75 TIME_WAIT 915148800.75
1999-01-01T00:00:33.00 1999-01-01T00:00:01.00 TIME_WAIT 915148801.00
1999-01-01T00:00:33.25 1999-01-01T00:00:01.25 TIME_WAIT 915148801.25

This can be decoded properly by paying attention to the leap second state variable, which unambiguously indicates whether the leap has been performed yet. The state variable change is synchronous with the leap.

A similar situation arises with a negative leap second, where the second that is skipped is slightly too late. Very briefly the system shows a nominally impossible time number, but this can be detected by the TIME_DEL state and corrected.

In this type of system the Unix time number violates POSIX around both types of leap second. Collecting the leap second state variable along with the time number allows for unambiguous decoding, so the correct POSIX time number can be generated if desired, or the full UTC time can be stored in a more suitable format.

The decoding logic required to cope with this style of Unix clock would also correctly decode a hypothetical POSIX-conforming clock using the same interface. This would be achieved by indicating the TIME_INS state during the entirety of an inserted leap second, then indicating TIME_WAIT during the entirety of the following second while repeating the seconds count. This requires synchronous leap second handling. This is probably the best way to express UTC time in Unix clock form, via a Unix interface, when the underlying clock is fundamentally untroubled by leap seconds.

TAI-based variant[edit]

Another, much rarer, non-conforming variant of Unix time keeping involves encoding TAI rather than UTC; some Linux systems are configured this way.[10] Because TAI has no leap seconds, and every TAI day is exactly 86400 seconds long, this encoding is actually a pure linear count of seconds elapsed since 1970-01-01T00:00:00 TAI. This makes time interval arithmetic much easier. Time values from these systems do not suffer the ambiguity that strictly conforming POSIX systems or NTP-driven systems have.

In these systems it is necessary to consult a table of leap seconds to correctly convert between UTC and the pseudo-Unix-time representation. This resembles the manner in which time zone tables must be consulted to convert to and from civil time; the IANA time zone database includes leap second information, and the sample code available from the same source uses that information to convert between TAI-based time stamps and local time. Conversion also runs into definitional problems prior to the 1972 commencement of the current form of UTC (see section UTC basis below).

This TAI-based system, despite its superficial resemblance, is not Unix time. It encodes times with values that differ by several seconds from the POSIX time values. A version of this system was proposed for inclusion in ISO C's , but only the UTC part was accepted in 2011.[11] A does, however, exist in C++20.

Representing the number[edit]

A Unix time number can be represented in any form capable of representing numbers. In some applications the number is simply represented textually as a string of decimal digits, raising only trivial additional problems. However, certain binary representations of Unix times are particularly significant.

The Unix data type that represents a point in time is, on many platforms, a signed integer, traditionally of 32 bits (but see below), directly encoding the Unix time number as described in the preceding section. Being 32 bits means that it covers a range of about 136 years in total. The minimum representable date is Friday 1901-12-13, and the maximum representable date is Tuesday 2038-01-19. One second after 03:14:07 UTC 2038-01-19 this representation will overflow in what is known as the year 2038 problem.

In some newer operating systems, has been widened to 64 bits. This expands the times representable by approximately 293 billion years in both directions, which is over twenty times the present age of the universe per direction.

There was originally some controversy over whether the Unix should be signed or unsigned. If unsigned, its range in the future would be doubled, postponing the 32-bit overflow (by 68 years). However, it would then be incapable of representing times prior to the epoch. The consensus is for to be signed, and this is the usual practice. The software development platform for version 6 of the QNX operating system has an unsigned 32-bit , though older releases used a signed type.

The POSIX and Open Group Unix specifications include the C standard library, which includes the time types and functions defined in the header file. The ISO C standard states that must be an arithmetic type, but does not mandate any specific type or encoding for it. POSIX requires to be an integer type, but does not mandate that it be signed or unsigned.

Unix has no tradition of directly representing non-integer Unix time numbers as binary fractions. Instead, times with sub-second precision are represented using composite data types that consist of two integers, the first being a (the integral part of the Unix time), and the second being the fractional part of the time number in millionths (in ) or billionths (in ).[12][13] These structures provide a decimal-based fixed-point data format, which is useful for some applications, and trivial to convert for others.

UTC basis[edit]

The present form of UTC, with leap seconds, is defined only starting from 1 January 1972. Prior to that, since 1 January 1961 there was an older form of UTC in which not only were there occasional time steps, which were by non-integer numbers of seconds, but also the UTC second was slightly longer than the SI second, and periodically changed to continuously approximate the Earth's rotation. Prior to 1961 there was no UTC, and prior to 1958 there was no widespread atomic timekeeping; in these eras, some approximation of GMT (based directly on the Earth's rotation) was used instead of an atomic timescale.[citation needed]

The precise definition of Unix time as an encoding of UTC is only uncontroversial when applied to the present form of UTC. The Unix epoch predating the start of this form of UTC does not affect its use in this era: the number of days from 1 January 1970 (the Unix epoch) to 1 January 1972 (the start of UTC) is not in question, and the number of days is all that is significant to Unix time.

The meaning of Unix time values below +63072000 (i.e., prior to 1 January 1972) is not precisely defined. The basis of such Unix times is best understood to be an unspecified approximation of UTC. Computers of that era rarely had clocks set sufficiently accurately to provide meaningful sub-second timestamps in any case. Unix time is not a suitable way to represent times prior to 1972 in applications requiring sub-second precision; such applications must, at least, define which form of UT or GMT they use.

As of 2009[update], the possibility of ending the use of leap seconds in civil time is being considered.[14] A likely means to execute this change is to define a new time scale, called International Time, that initially matches UTC but thereafter has no leap seconds, thus remaining at a constant offset from TAI. If this happens, it is likely that Unix time will be prospectively defined in terms of this new time scale, instead of UTC. Uncertainty about whether this will occur makes prospective Unix time no less predictable than it already is: if UTC were simply to have no further leap seconds the result would be the same.


The earliest versions of Unix time had a 32-bit integer incrementing at a rate of 60 Hz, which was the rate of the system clock on the hardware of the early Unix systems. The value 60 Hz still appears in some software interfaces as a result. The epoch also differed from the current value. The first edition Unix Programmer's Manual dated 3 November 1971 defines the Unix time as "the time since 00:00:00, 1 January 1971, measured in sixtieths of a second".[15]

The User Manual also commented that "the chronologically-minded user will note that 2**32 sixtieths of a second is only about 2.5 years". Because of this limited range, the epoch was redefined more than once, before the rate was changed to 1 Hz and the epoch was set to its present value of 1 January 1970 00:00:00 UTC. This yielded a range of about 136 years, half of it before 1970 and half of it afterwards.

As indicated by the definition quoted above, the Unix time scale was originally intended to be a simple linear representation of time elapsed since an epoch. However, there was no consideration of the details of time scales, and it was implicitly assumed that there was a simple linear time scale already available and agreed upon. The first edition manual's definition does not even specify which time zone is used. Several later problems, including the complexity of the present definition, result from Unix time having been defined gradually by usage rather than fully defined from the outset.

When POSIX.1 was written, the question arose of how to precisely define in the face of leap seconds. The POSIX committee considered whether Unix time should remain, as intended, a linear count of seconds since the epoch, at the expense of complexity in conversions with civil time or a representation of civil time, at the expense of inconsistency around leap seconds. Computer clocks of the era were not sufficiently precisely set to form a precedent one way or the other.

The POSIX committee was swayed by arguments against complexity in the library functions,[citation needed] and firmly defined the Unix time in a simple manner in terms of the elements of UTC time. This definition was so simple that it did not even encompass the entire leap year rule of the Gregorian calendar, and would make 2100 a leap year.

The 2001 edition of POSIX.1 rectified the faulty leap year rule in the definition of Unix time, but retained the essential definition of Unix time as an encoding of UTC rather than a linear time scale. Since the mid-1990s, computer clocks have been routinely set with sufficient precision for this to matter, and they have most commonly been set using the UTC-based definition of Unix time. This has resulted in considerable complexity in Unix implementations, and in the Network Time Protocol, to execute steps in the Unix time number whenever leap seconds occur.[citation needed]

Notable events in Unix time[edit]

Unix enthusiasts have a history of holding "time_t parties" (pronounced "time tea parties") to celebrate significant values of the Unix time number.[16][17] These are directly analogous to the new year celebrations that occur at the change of year in many calendars. As the use of Unix time has spread, so has the practice of celebrating its milestones. Usually it is time values that are round numbers in decimal that are celebrated, following the Unix convention of viewing values in decimal. Among some groups round binary numbers are also celebrated, such as +230 which occurred at 13:37:04 UTC on Saturday, 10 January 2004.[citation needed]

The events that these celebrate are typically described as "N seconds since the Unix epoch", but this is inaccurate; as discussed above, due to the handling of leap seconds in Unix time the number of seconds elapsed since the Unix epoch is slightly greater than the Unix time number for times later than the epoch.

  • At 18:36:57 UTC on Wednesday, 17 October 1973, the first appearance of the date in ISO 8601 format[a](1973-10-17) within the digits of Unix time (119731017) took place.
  • At 01:46:40 UTC on Sunday, 9 September 2001, the Unix billennium (Unix time number 1000000000) was celebrated.[18] The name billennium is a portmanteau of billion and millennium.[19][20] Some programs which stored timestamps using a text representation encountered sorting errors, as in a text sort times after the turnover, starting with a 1 digit, erroneously sorted before earlier times starting with a 9 digit. Affected programs included the popular Usenet reader KNode and e-mail client KMail, part of the KDE desktop environment. Such bugs were generally cosmetic in nature and quickly fixed once problems became apparent. The problem also affected many Filtrix document-format filters provided with Linux versions of WordPerfect; a patch was created by the user community to solve this problem, since Corel no longer sold or supported that version of the program.[21]
  • At 23:31:30 UTC on Friday, 13 February 2009, the decimal representation of Unix time reached 1234567890 seconds.[22]Google celebrated this with a Google doodle.[23] Parties and other celebrations were held around the world, among various technical subcultures, to celebrate the 1234567890th second.[16][24]
  • At 03:33:20 UTC on Wednesday, 18 May 2033, the Unix time value will equal 2000000000 seconds.
  • At 06:28:16 UTC on Thursday, 7 February 2036, Network Time Protocol will loop over to the next epoch, as the 32-bit time stamp value used in NTP (unsigned, but based on 1 January 1900) will overflow. This date is close to the following date because the 136-year range of a 32-bit integer number of seconds is close to twice the 70-year offset between the two epochs.
  • At 03:14:08 UTC on Tuesday, 19 January 2038, 32-bit versions of the Unix timestamp will cease to work, as it will overflow the largest value that can be held in a signed 32-bit number (7FFFFFFF16 or 2147483647). Before this moment, software using 32-bit time stamps will need to adopt a new convention for time stamps,[25] and file formats using 32-bit time stamps will need to be changed to support larger time stamps or a different epoch. If unchanged, the next second will be incorrectly interpreted as 20:45:52 Friday 13 December 1901 UTC. This is referred to as the Year 2038 problem.
  • At 05:20:00 UTC on Saturday, 24 January 2065, the Unix time value will equal 3000000000 seconds.
  • At 06:28:15 UTC on Sunday, 7 February 2106, the Unix time will reach FFFFFFFF16 or 4294967295 seconds, which, for systems that hold the time on 32-bit unsigned integers, is the maximum attainable. For some of these systems, the next second will be incorrectly interpreted as 00:00:00 Thursday 1 January 1970 UTC. Other systems may experience an overflow error with unpredictable outcomes.[citation needed]
  • At 15:30:08 UTC on Sunday, 4 December 292277026596,[26][27] 64-bit versions of the Unix time stamp cease to work, as it will overflow the largest value that can be held in a signed 64-bit number. This is nearly 22 times the estimated current age of the universe, which is 1.37×1010 years (13.7 billion).

In literature and calendrics[edit]

Vernor Vinge's novel A Deepness in the Sky describes a spacefaring trading civilization thousands of years in the future that still uses the Unix epoch. The "programmer-archaeologist" responsible for finding and maintaining usable code in mature computer systems first believes that the epoch refers to the time when man first walked on the Moon, but then realizes that it is "the 0-second of one of Humankind's first computer operating systems".[28]

See also[edit]


  1. ^cited retroactively since ISO 8601 was published in 1988.


  1. ^"The Open Group Base Specifications Issue 7, Rationale: Base Definitions, section A.4 General Concepts". The Open Group. Retrieved 9 September 2019.
  2. ^ abcd"The Open Group Base Specifications Issue 7, section 4.16 Seconds Since the Epoch". The Open Group. Retrieved 22 January 2017.
  3. ^Matthew, Neil; Stones, Richard (2008). "The Linux Environment". Beginning Linux Programming. Indianapolis, Indiana, US: Wiley. p. 148. ISBN .
  4. ^ – Commands & Utilities Reference, The Single UNIX Specification, Issue 7 from The Open Group
  5. ^"Epoch Converter - Unix Timestamp Converter". Epoch Converter. Retrieved 12 January 2020.
  6. ^"Handling timestamps using Format Date in Shortcuts". Apple Inc. Retrieved 19 June 2019.
  7. ^"RAW date format in CSV exported reports". International Business Machines Corporation (IBM). Retrieved 19 June 2019.
  8. ^"TIMESTAMP BY (Azure Stream Analytics)". Microsoft Corporation. Retrieved 19 June 2019.
  9. ^Mills, David L. (12 May 2012). "The NTP Timescale and Leap Seconds". eecis.udel.edu. Retrieved 21 August 2017.
  10. ^"Time Scales". Network Time Protocol Wiki. 24 July 2019. Retrieved 12 January 2020.
  11. ^Markus Kuhn. "Modernized API for ISO C". www.cl.cam.ac.uk.
  12. ^"timespec". NetBSD Manual Pages. 12 April 2011. Retrieved 5 July 2019.
  13. ^"time.h(0P)". Linux manual page. Retrieved 5 July 2019.
  14. ^McCarthy, D. D.; Seidelmann, P. K. (2009). TIME—From Earth Rotation to Atomic Physics. Weinheim: Wiley–VCH Verlag GmbH & Co. KGaA. p. 232. ISBN .
  15. ^Unix Programmer's Manual(PDF) (1st ed.). 3 November 1971. Retrieved 28 March 2012.
  16. ^ abTweney, Dylan (12 February 2009). "Unix Lovers to Party Like It's 1234567890". Wired.
  17. ^"Slashdot | date +%s Turning 1111111111". 17 March 2005.[unreliable source?]
  18. ^"Unix time facts & trivia – Unix Time . Info". Archived from the original on 27 October 2017.
  19. ^"UNIX Approaches Ripe Old Age of One Billion". Electromagnetic.net. Archived from the original on 13 April 2013. Retrieved 6 December 2012.
  20. ^"The Risks Digest Volume 21: Issue 69". Catless.ncl.ac.uk. Retrieved 6 December 2012.
  21. ^"Technical Problems". linuxmafia.com. Retrieved 21 August 2017.
  22. ^nixCraft. "Humor: On Feb, Friday 13, 2009 Unix time Will Be 1234567890". Cyberciti.biz. Retrieved 6 December 2012.
  23. ^"Google 1234567890 Logo". Google Inc. Retrieved 28 January 2013.
  24. ^Ahmed, Murad (13 February 2009). "At the third stroke, the Unix time will be 1234567890". The Times.
  25. ^"Unix Time Stamp.com". UnixTimeStamp.com. Retrieved 12 January 2020.
  26. ^Spinellis, Diomidis (7 April 2006). Code Quality: The Open Source Perspective. ISBN .
  27. ^IDRBT Working Paper No. 9 Y2K38 – Ashutosh Saxena and Sanjay Rawat
  28. ^Mashey, John R. (27 December 2004). "Languages, Levels, Libraries, and Longevity". Queue. 2 (9): 32–38. doi:10.1145/1039511.1039532. S2CID 28911378.

External links[edit]

Sours: https://en.wikipedia.org/wiki/Unix_time

Time epoch

What is the unix time stamp?

The unix time stamp is a way to track time as a running total of seconds. This count starts at the Unix Epoch on January 1st, 1970 at UTC. Therefore, the unix time stamp is merely the number of seconds between a particular date and the Unix Epoch. It should also be pointed out (thanks to the comments from visitors to this site) that this point in time technically does not change no matter where you are located on the globe. This is very useful to computer systems for tracking and sorting dated information in dynamic and distributed applications both online and client side.

Human Readable TimeSeconds
1 Hour3600 Seconds
1 Day86400 Seconds
1 Week604800 Seconds
1 Month (30.44 days)2629743 Seconds
1 Year (365.24 days)31556926 Seconds

What happens on January 19, 2038?

On this date the Unix Time Stamp will cease to work due to a 32-bit overflow. Before this moment millions of applications will need to either adopt a new convention for time stamps or be migrated to 64-bit systems which will buy the time stamp a "bit" more time.

Sours: https://www.unixtimestamp.com/index.php


Now discussing:


354 355 356 357 358