Unix time

Last updated
Current Unix time
1560753052 (update)
(2019-06-17T06:30:52+00:00)
Unix time passed 1000000000 seconds in 2001-09-09T01:46:40Z. It was celebrated in Copenhagen, Denmark at a party held by DKUUG (at 03:46:40 local time). 1000000000seconds.jpg
Unix time passed 1000000000 seconds in 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 POSIX time [1] [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 00:00:00 Thursday, 1 January 1970, [2] Coordinated Universal Time (UTC), minus leap seconds. Every day is treated as if it contains exactly 86400 seconds, [2] so leap seconds are to be subtracted since the epoch. [4] It is used widely in Unix-like and many other operating systems and file formats. However, Unix time is not a true representation of UTC, as a leap second in UTC shares the same Unix time as the second which came before it. Unix time may be checked on most Unix systems by typing date +%s on the command line.

Time dimension in which events can be ordered from the past through the present into the future

Time is the indefinite continued progress of existence and events that occur in apparently irreversible succession from the past, through the present, to the future. Time is a component quantity of various measurements used to sequence events, to compare the duration of events or the intervals between them, and to quantify rates of change of quantities in material reality or in the conscious experience. Time is often referred to as a fourth dimension, along with three spatial dimensions.

Second SI unit of time

The second is the base unit of time in the International System of Units (SI), commonly understood and historically defined as ​186400 of a day – this factor derived from the division of the day first into 24 hours, then to 60 minutes and finally to 60 seconds each. Analog clocks and watches often have sixty tick marks on their faces, representing seconds, and a "second hand" to mark the passage of time in seconds. Digital clocks and watches often have a two-digit seconds counter. The second is also part of several other units of measurement like meters per second for velocity, meters per second per second for acceleration, and per second for frequency.

Coordinated Universal Time Primary time standard by which the world regulates clocks and time

Coordinated Universal Time is the primary time standard by which the world regulates clocks and time. It is within about 1 second of mean solar time at 0° longitude, and is not adjusted for daylight saving time. In some countries where English is spoken, the term Greenwich Mean Time (GMT) is often used as a synonym for UTC and predates UTC by nearly 300 years.

Contents

On systems where Unix time is stored as a signed 32-bit integer, the largest value that can be recorded is 2147483647 (231 − 1), which is 03:14:07 Tuesday, 19 January 2038 UTC. The following second, the clock will wrap around to negative 2147483648 (−231), which is 20:45:52 Friday, 13 December 1901 UTC. This is referred to as the Year 2038 problem .

Integer overflow Event when the result of computer arithmetic requires more bits than the data type can represent; must be treated carefully or it can cause security or safety hazards

In computer programming, an integer overflow occurs when an arithmetic operation attempts to create a numeric value that is outside of the range that can be represented with a given number of digits – either larger than the maximum or lower than the minimum representable value.

Year 2038 problem Problem affects all software and systems that both store system time as a signed 32-bit integer

The Year 2038 problem relates to representing time in many digital systems as the number of seconds passed since 1 January 1970 and storing it as a signed 32-bit binary integer. Such implementations cannot encode times after 03:14:07 UTC on 19 January 2038. Just like the Y2K problem, the Year 2038 problem is caused by insufficient capacity of the chosen storage unit.

Definition

Two layers of encoding make up Unix time. The first layer encodes a point in time as a scalar real 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.

Scalar (mathematics) elements of a field, e.g. real numbers, in the context of linear algebra

A scalar is an element of a field which is used to define a vector space. A quantity described by multiple scalars, such as having both direction and magnitude, is called a vector.

Real number Number representing a continuous quantity

In mathematics, a real number is a value of a continuous quantity that can represent a distance along a line. The adjective real in this context was introduced in the 17th century by René Descartes, who distinguished between real and imaginary roots of polynomials. The real numbers include all the rational numbers, such as the integer −5 and the fraction 4/3, and all the irrational numbers, such as 2. Included within the irrationals are the transcendental numbers, such as π (3.14159265...). In addition to measuring distance, real numbers can be used to measure quantities such as time, mass, energy, velocity, and many more.

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.

The Gregorian calendar is the calendar used in most of the world. It is named after Pope Gregory XIII, who introduced it in October 1582. The calendar spaces leap years to make the average year 365.2425 days long, approximating the 365.2422-day tropical year that is determined by the Earth's revolution around the Sun. The rule for leap years is:

Every year that is exactly divisible by four is a leap year, except for years that are exactly divisible by 100, but these centurial years are leap years if they are exactly divisible by 400. For example, the years 1700, 1800, and 1900 are not leap years, but the year 2000 is.

International Atomic Time is a high-precision atomic coordinate time standard based on the notional passage of proper time on Earth's geoid. It is the principal realisation of Terrestrial Time. It is also the basis for Coordinated Universal Time (UTC), which is used for civil timekeeping all over the Earth's surface. As of 31 December 2016, when another leap second was added, TAI is exactly 37 seconds ahead of UTC. The 37 seconds results from the initial difference of 10 seconds at the start of 1972, plus 27 leap seconds in UTC since 1972.

Synchronization coordination of events to operate a system in unison

Synchronization is the coordination of events to operate a system in unison. The conductor of an orchestra keeps the orchestra synchronized or in time. Systems that operate with all parts in synchrony are said to be synchronous or in sync—and those that are not are asynchronous.

Encoding time as a number

Unix time is a single signed number which increments every second, without requiring the calculations to determine year, month, day of month, hour and minute required for intelligibility to humans.

The Unix epoch is the time 00:00:00 UTC on 1 January 1970. 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.

In computing, an epoch is a date and time from which a computer measures system time. Most computer systems determine time as a number representing the seconds removed from particular arbitrary date and time. For instance, Unix and POSIX measure time as the number of seconds that have passed since 1 January 1970 00:00:00 UT, a point in time known as the Unix epoch.

ISO 8601Data elements and interchange formats – Information interchange – Representation of dates and times is an international standard covering the exchange of date- and time-related data. It was issued by the International Organization for Standardization (ISO) and was first published in 1988. The purpose of this standard is to provide an unambiguous and well-defined method of representing dates and times, so as to avoid misinterpretation of numeric representations of dates and times, particularly when data are transferred between countries with different conventions for writing numeric dates and times.

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.

Within each day, the Unix time number is calculated as in the preceding paragraph at midnight UTC (00:00:00Z), and increases by exactly 1 per second since midnight. Thus, 2004-09-16T17:55:43.54Z, 64543.54 seconds since midnight on the first day in the example above, is represented by the Unix time number 1095292800 + 64543.54 = 1095357343.54. On dates before the epoch, the number still increases, thus becoming less negative as time moves forward.

Occasionally, those unfamiliar with any other epoch than the Unix epoch have mistakenly referred to Unix time as "epoch time". This name is misleading, and should be avoided, not only because there are many other epochs, but also because all absolute timekeeping systems must denote time relative to some epoch.

Leap seconds

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:

Unix time across midnight into 17 September 2004 (no leap second)
TAI (17 September 2004)UTC (16 to 17 September 2004)Unix time
2004-09-17T00:00:30.752004-09-16T23:59:58.751095379198.75
2004-09-17T00:00:31.002004-09-16T23:59:59.001095379199.00
2004-09-17T00:00:31.252004-09-16T23:59:59.251095379199.25
2004-09-17T00:00:31.502004-09-16T23:59:59.501095379199.50
2004-09-17T00:00:31.752004-09-16T23:59:59.751095379199.75
2004-09-17T00:00:32.002004-09-17T00:00:00.001095379200.00
2004-09-17T00:00:32.252004-09-17T00:00:00.251095379200.25
2004-09-17T00:00:32.502004-09-17T00:00:00.501095379200.50
2004-09-17T00:00:32.752004-09-17T00:00:00.751095379200.75
2004-09-17T00:00:33.002004-09-17T00:00:01.001095379201.00
2004-09-17T00:00:33.252004-09-17T00:00:01.251095379201.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. At the end of a day with a negative leap second, which has not yet occurred, 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:

Unix time across midnight into 1 January 1999 (positive leap second)
TAI (1 January 1999)UTC (31 December 1998 to 1 January 1999)Unix time
1999-01-01T00:00:29.751998-12-31T23:59:58.75915148798.75
1999-01-01T00:00:30.001998-12-31T23:59:59.00915148799.00
1999-01-01T00:00:30.251998-12-31T23:59:59.25915148799.25
1999-01-01T00:00:30.501998-12-31T23:59:59.50915148799.50
1999-01-01T00:00:30.751998-12-31T23:59:59.75915148799.75
1999-01-01T00:00:31.001998-12-31T23:59:60.00915148800.00
1999-01-01T00:00:31.251998-12-31T23:59:60.25915148800.25
1999-01-01T00:00:31.501998-12-31T23:59:60.50915148800.50
1999-01-01T00:00:31.751998-12-31T23:59:60.75915148800.75
1999-01-01T00:00:32.001999-01-01T00:00:00.00915148800.00
1999-01-01T00:00:32.251999-01-01T00:00:00.25915148800.25
1999-01-01T00:00:32.501999-01-01T00:00:00.50915148800.50
1999-01-01T00:00:32.751999-01-01T00:00:00.75915148800.75
1999-01-01T00:00:33.001999-01-01T00:00:01.00915148801.00
1999-01-01T00:00:33.251999-01-01T00:00:01.25915148801.25

Unix time numbers are repeated in the second immediately following a positive leap second. The Unix time number 915148800.50 is thus ambiguous: it can refer either to the instant in the middle of the leap second, or to the instant one second later, half a second after midnight UTC. 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 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 UTC 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

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. [6] This is what happens across a positive leap second:

Non-synchronous Mills-style Unix clock
across midnight into 1 January 1999 (positive leap second)
TAI (1 January 1999)UTC (31 December 1998 to 1 January 1999)StateUnix clock
1999-01-01T00:00:29.751998-12-31T23:59:58.75TIME_INS915148798.75
1999-01-01T00:00:30.001998-12-31T23:59:59.00TIME_INS915148799.00
1999-01-01T00:00:30.251998-12-31T23:59:59.25TIME_INS915148799.25
1999-01-01T00:00:30.501998-12-31T23:59:59.50TIME_INS915148799.50
1999-01-01T00:00:30.751998-12-31T23:59:59.75TIME_INS915148799.75
1999-01-01T00:00:31.001998-12-31T23:59:60.00TIME_INS915148800.00
1999-01-01T00:00:31.251998-12-31T23:59:60.25TIME_OOP915148799.25
1999-01-01T00:00:31.501998-12-31T23:59:60.50TIME_OOP915148799.50
1999-01-01T00:00:31.751998-12-31T23:59:60.75TIME_OOP915148799.75
1999-01-01T00:00:32.001999-01-01T00:00:00.00TIME_OOP915148800.00
1999-01-01T00:00:32.251999-01-01T00:00:00.25TIME_WAIT915148800.25
1999-01-01T00:00:32.501999-01-01T00:00:00.50TIME_WAIT915148800.50
1999-01-01T00:00:32.751999-01-01T00:00:00.75TIME_WAIT915148800.75
1999-01-01T00:00:33.001999-01-01T00:00:01.00TIME_WAIT915148801.00
1999-01-01T00:00:33.251999-01-01T00:00:01.25TIME_WAIT915148801.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

Another, much rarer, non-conforming variant of Unix time keeping involves encoding TAI rather than UTC; some Linux systems are configured this way. [7] 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, and does not have the simple mathematical relationship to UTC that is mandated by POSIX.

Representing the number

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 time_t 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. This milestone is anticipated with a mixture of amusement and dread—see year 2038 problem.

In some newer operating systems, time_t 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 time_t 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 time_t 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 time_t, 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 <time.h> header file. The ISO C standard states that time_t must be an arithmetic type, but does not mandate any specific type or encoding for it. POSIX requires time_t 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 time_t (the integral part of the Unix time), and the second being the fractional part of the time number in millionths (in struct timeval) or billionths (in struct timespec). These structures provide a decimal-based fixed-point data format, which is useful for some applications, and trivial to convert for others.

UTC basis

The present form of UTC, with leap seconds, is defined only from 1 January 1972 onwards. 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, the possibility of ending the use of leap seconds in civil time is being considered. [8] 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.

Command line

In Unix-like operating systems, date is the command which will print or set the current time. [9]

History

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". [10]

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, though with more than half the range in the past (see discussion of signedness above).

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 time_t 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.

Non-Gregorian calendars

The UNIX Epoch (time 0) in non-Gregorian calendars
CalendarDateAdditional information
Julian 19-December-1969Fell on a Thursday
Hebrew 5730-Teveth-23 Embolismic deficient (383-day year)
Islamic 1389-Shawwal-22Fell on a yawm al-khamis
Persian 1348 Dey 11Fell on a Panjshanbeh (Thursday)
Mayan 12.17.16.7.5 Lord of the night was G1
Chinese Yi-Chou (Ox), 24, 4667Year Name was Ji You (Rooster)

Notable events in Unix time

Unix enthusiasts have a history of holding "time_t parties" to celebrate significant values of the Unix time number. [11] [12] 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 time_t 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.

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.

In literature and calendrics

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". [24]

See also

Related Research Articles

Leap second Extra second inserted to keep civil time in sync with the Earths rotation

A leap second is a one-second adjustment that is occasionally applied to civil time Coordinated Universal Time (UTC) to keep it close to the mean solar time at Greenwich, in spite of the Earth's rotation slowdown and irregularities. UTC was introduced on January 1, 1972, initially with a 10 second lag behind International Atomic Time (TAI). Since that date, 27 leap seconds have been inserted, the most recent on December 31, 2016 at 23:59:60 UTC, so in 2018, UTC lags behind TAI by an offset of 37 seconds.

Terrestrial Time (TT) is a modern astronomical time standard defined by the International Astronomical Union, primarily for time-measurements of astronomical observations made from the surface of Earth. For example, the Astronomical Almanac uses TT for its tables of positions (ephemerides) of the Sun, Moon and planets as seen from Earth. In this role, TT continues Terrestrial Dynamical Time, which in turn succeeded ephemeris time (ET). TT shares the original purpose for which ET was designed, to be free of the irregularities in the rotation of Earth.

Julian day is the continuous count of days since the beginning of the Julian Period and is used primarily by astronomers, and in software for easily calculating elapsed days between two events.

Metric time is the measure of time intervals using the metric system. The modern SI system defines the second as the base unit of time, and forms multiples and submultiples with metric prefixes such as kiloseconds and milliseconds. Other units of time: minute, hour, and day, are accepted for use with SI, but are not part of it. Metric time is a measure of time intervals, while decimal time is a means of recording time of day.

Time from NPL (MSF)

The Time from NPL is a radio signal broadcast from the Anthorn Radio Station near Anthorn, Cumbria, which serves as the United Kingdom's national time reference. The time signal is derived from three atomic clocks installed at the transmitter site, and is based on time standards maintained by the UK's National Physical Laboratory (NPL) in Teddington. The service is provided by Babcock International, under contract to the NPL. It was funded by the former Department for Business, Innovation and Skills; as of 2017 NPL Management Limited (NPLML) was owned by the Department for Business, Energy and Industrial Strategy (BEIS), and NPL operated as a public corporation.

WWV (radio station) Shortwave radio station broadcasting time signals

WWV is a shortwave radio station, located near Fort Collins, Colorado. It is best known for its continuous time signal broadcasts begun in 1945, and is also used to establish official United States government frequency standards, with transmitters operating on 2.5, 5, 10, 15, and 20 MHz. WWV is operated by U.S. National Institute of Standards and Technology (NIST), under the oversight of its Time and Frequency Division, which is part of NIST's Physical Measurement Laboratory based in Gaithersburg, Maryland.

WWVB Radio station

WWVB is a time signal radio station near Fort Collins, Colorado and is operated by the National Institute of Standards and Technology (NIST). Most radio-controlled clocks in North America use WWVB's transmissions to set the correct time. The 70 kW ERP signal transmitted from WWVB is a continuous 60 kHz carrier wave, the frequency of which is derived from a set of atomic clocks located at the transmitter site, yielding a frequency uncertainty of less than 1 part in 1012. A one-bit-per-second time code, which is based on the IRIG "H" time code format and derived from the same set of atomic clocks, is then modulated onto the carrier wave using pulse-width modulation and amplitude-shift keying. A single complete frame of time code begins at the start of each minute, lasts one minute, and conveys the year, day of year, hour, minute, and other information such as the beginning of the minute.

The Common Object File Format (COFF) is a format for executable, object code, and shared library computer files used on Unix systems. It was introduced in Unix System V, replaced the previously used a.out format, and formed the basis for extended specifications such as XCOFF and ECOFF, before being largely replaced by ELF, introduced with SVR4. COFF and its variants continue to be used on some Unix-like systems, on Microsoft Windows, in EFI environments and in some embedded development systems.

2,147,483,647 Natural number

The number 2,147,483,647 is the eighth Mersenne prime, equal to 231 − 1. It is one of only four known double Mersenne primes.

Decimal time representation of the time of day using units which are decimally related

Decimal time is the representation of the time of day using units which are decimally related. This term is often used specifically to refer to the time system used in France for a few years beginning in 1792 during the French Revolution, which divided the day into 10 decimal hours, each decimal hour into 100 decimal minutes and each decimal minute into 100 decimal seconds, as opposed to the more familiar UTC time standard, which divides the day into 24 hours, each hour into 60 minutes and each minute into 60 seconds.

In computer science and computer programming, system time represents a computer system's notion of the passage of time. In this sense, time also includes the passing of days on the calendar.

In computer science, time formatting and storage bugs are a class of software bugs which may cause time and date calculation or display to be improperly handled. These are most commonly manifestations of arithmetic overflow, but can also be the result of other issues. The most well-known consequence of bugs of this type is the Y2K problem, but many other milestone dates or times exist that have caused or will cause problems depending on various programming deficiencies.

PDB is a container format for record databases in Palm OS, Garnet OS and Access Linux Platform. Its structure is similar to PRC resource databases. The PalmDOC eBook format is a special version of the PDB format.

The Time-based One-Time Password algorithm (TOTP) is an extension of the HMAC-based One-time Password algorithm (HOTP) generating a one-time password by instead taking uniqueness from the current time. It has been adopted as Internet Engineering Task Force standard RFC 6238, is the cornerstone of Initiative For Open Authentication (OATH), and is used in a number of two-factor authentication systems.

The number 9,223,372,036,854,775,807 is the integer equal to 263 − 1. Its prime factorization is 72 · 73 · 127 · 337 · 92737 · 649657, which is equal to Φ1(2) · Φ3(2) · Φ7(2) · Φ9(2) · Φ21(2) · Φ63(2).

References

  1. "The Base Specifications Issue 7". The Open Group . Retrieved 14 May 2019.
  2. 1 2 3 "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   978-0-470-14762-7.
  4. "The Open Group Base Specifications Issue 7, Rationale, section 4.16 Seconds Since the Epoch". The OpenGroup. Retrieved 22 January 2017.
  5. "Epoch Converter - Unix Timestamp Converter". Epoch Converter. Retrieved 9 February 2017.
  6. Mills, David L. (12 May 2012). "The NTP Timescale and Leap Seconds". eecis.udel.edu. Retrieved 21 August 2017.
  7. "Time Scales". Network Time Protocol Wiki. Retrieved 4 January 2013.
  8. McCarthy, D. D.; Seidelmann, P. K. (2009). TIME—From Earth Rotation to Atomic Physics. Weinheim: Wiley–VCH Verlag GmbH & Co. KGaA. p. 232. ISBN   978-3-527-40780-4.
  9. date   Commands & Utilities Reference, The Single UNIX Specification , Issue 7 from The Open Group
  10. Unix Programmer's Manual (PDF) (1st ed.). 3 November 1971. Retrieved 28 March 2012. time returns the time since 00:00:00, 1 Jan. 1971, measured in sixtieths of a second.
  11. Tweney, Dylan (12 February 2009). "Unix Lovers to Party Like It's 1234567890". Wired. Retrieved 9 August 2013.
  12. "Slashdot | date +%s Turning 1111111111" . Retrieved 14 July 2007.[ unreliable source? ]
  13. "Unix time facts & trivia – Unix Time . Info". Archived from the original on 27 October 2017.
  14. "UNIX Approaches Ripe Old Age of One Billion". Electromagnetic.net. Archived from the original on 13 April 2013. Retrieved 6 December 2012.
  15. "The Risks Digest Volume 21: Issue 69". Catless.ncl.ac.uk. Retrieved 6 December 2012.
  16. "Technical Problems". linuxmafia.com. Retrieved 21 August 2017.
  17. nixCraft. "Humor: On Feb, Friday 13, 2009 Unix time Will Be 1234567890". Cyberciti.biz. Retrieved 6 December 2012.
  18. "Google 1234567890 Logo". Google Inc. Retrieved 28 January 2013.
  19. Tweney, Dylan (12 February 2009). "Unix Lovers to Party Like It's 1234567890". Wired News.
  20. Ahmed, Murad (13 February 2009). "At the third stroke, the Unix time will be 1234567890". Times Online.
  21. "Unix Time Stamp.com". Unixtimestamp.com. Retrieved 6 December 2012.
  22. Spinellis, Diomidis (7 April 2006). "Code Quality: The Open Source Perspective". ISBN   9780321166074.
  23. IDRBT Working Paper No. 9 Y2K38 – Ashutosh Saxena and Sanjay Rawat
  24. Mashey, John R. (27 December 2004). "Languages, Levels, Libraries, and Longevity". Queue. 2 (9): 32–38.