Misplaced Pages

#241758

55-404: X32 may refer to: X.32 , an old ITU-T standard for connecting to an X.25 network by dial-up x32 ABI , a Linux and BSD Application Binary Interface ×32, a PCI Express connector slot x32, 32-bit computing Boeing X-32 , a jet fighter aircraft X32 Digital Mixing Console , manufactured by Behringer IA-32 , the 32-bit version of

110-459: 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

165-655: A Date library which provides and stores timestamps in milliseconds since the Unix epoch and is implemented in all modern desktop and mobile web browsers as well as in JavaScript server environments like Node.js . Filesystems designed for use with Unix-based operating systems tend to use Unix time. APFS , the file system used by default across all Apple devices, and ext4 , which is widely used on Linux and Android devices, both use Unix time in nanoseconds for file timestamps. Several archive file formats can store timestamps in Unix time, including RAR and tar . Unix time

220-485: A concern that the use of 32-bit time values in the x32 ABI could cause problems in the future. This is because the use of 32-bit time values would cause the time values to overflow in the year 2038 . Following this request, the developers of the x32 ABI changed the time values to 64-bit. A presentation at the Linux Plumbers Conference on September 7, 2011, covered the x32 ABI. The x32 ABI

275-416: 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

330-473: 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

385-556: A more precise measurement of time is needed, such as when measuring the execution time of programs. Unix time by design does not require a specific size for the storage, but most common implementations of Unix time use a signed integer with the same size as the word size of the underlying hardware. As the majority of modern computers are 32-bit or 64-bit , and a large number of programs are still written in 32-bit compatibility mode, this means that many programs using Unix time are using signed 32-bit integer fields. The maximum value of

440-570: 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

495-462: A normal UTC day, which has a duration of 86 400 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: When a leap second occurs, the UTC day is not exactly 86 400 seconds long and the Unix time number (which always increases by exactly 86 400 each day) experiences

550-420: A number of time format standards which exist to be readable by both humans and computers, such as ISO 8601 . Unix enthusiasts have a history of holding "time_t parties" (pronounced "time tea parties ") to celebrate significant values of the Unix time number. 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

605-463: 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. A signed 32-bit value covers about 68 years before and after the 1970-01-01 epoch. The minimum representable date is Friday 1901-12-13, and the maximum representable date is Tuesday 2038-01-19. One second after 2038-01-19T03:14:07Z this representation will overflow in what

SECTION 10

#1732771999242

660-516: A rate of 60  Hz , which was the rate of the system clock on the hardware of the early Unix systems. Timestamps stored this way could only represent a range of a little over two and a quarter years. The epoch being counted from was changed with Unix releases to prevent overflow, with midnight on 1 January 1971 and 1 January 1972 both being used as epochs during Unix's early development. Early definitions of Unix time also lacked timezones. The current epoch of 1 January 1970 00:00:00 UTC

715-433: A signed 32-bit integer is 2 − 1 , and the minimum value is −2 , making it impossible to represent dates before 13 December 1901 (at 20:45:52 UTC) or after 19 January 2038 (at 03:14:07 UTC). The early cutoff can have an impact on databases that are storing historical information; in some databases where 32-bit Unix time is used for timestamps, it may be necessary to store time in a different form of field, such as

770-474: A signed 64-bit integer is over 584 billion years, or 292 billion years in either direction of the 1970 epoch. Unix time is not the only standard for time that counts away from an epoch. On Windows , the FILETIME type stores time as a count of 100-nanosecond intervals that have elapsed since 0:00 GMT on 1 January 1601. Windows epoch time is used to store timestamps for files and in protocols such as

825-462: A string, to represent dates before 1901. The late cutoff is known as the Year 2038 problem and has the potential to cause issues as the date approaches, as dates beyond the 2038 cutoff would wrap back around to the start of the representable range in 1901. Date range cutoffs are not an issue with 64-bit representations of Unix time, as the effective range of dates representable with Unix time stored in

880-461: 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

935-450: Is also commonly used to store timestamps in databases, including in MySQL and PostgreSQL . Unix time was designed to encode calendar dates and times in a compact manner intended for use by computers internally. It is not intended to be easily read by humans or to store timezone-dependent values. It is also limited by default to representing time in seconds, making it unsuited for use when

990-470: Is also used as a mechanism for storing timestamps in a number of file systems , file formats , and databases . The C standard library uses Unix time for all date and time functions, and Unix time is sometimes referred to as time_t, the name of the data type used for timestamps in C and C++ . C's Unix time functions are defined as the system time API in the POSIX specification. The C standard library

1045-476: Is currently defined as the number of non-leap seconds which have passed since 00:00:00   UTC on Thursday, 1 January 1970, which is referred to as the Unix epoch . Unix time is typically encoded as a signed integer . The Unix time 0 is exactly midnight UTC on 1 January 1970, with Unix time incrementing by 1 for every non-leap second after this. For example, 00:00:00   UTC on 1 January 1971

1100-407: Is different from Wikidata All article disambiguation pages All disambiguation pages X32 ABI Though the x32 ABI limits the program to a virtual address space of 4 GiB, it also decreases the memory footprint of the program by making pointers smaller. This can allow it to run faster by fitting more code and more data into cache . The best results during testing were with

1155-431: Is known as the year 2038 problem . In some newer operating systems, time_t has been widened to 64 bits. This expands the times representable to about 292.3 billion years in both directions, which is over twenty times the present age of the universe . 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

SECTION 20

#1732771999242

1210-414: Is known), as opposed to "UTC" (although not all UTC time values have a unique reference in systems that do not count leap seconds). 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:10   TAI. This makes time interval arithmetic much easier. Time values from these systems do not suffer

1265-407: Is necessary to consult a table of leap seconds to detect them. 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. This

1320-458: 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. 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

1375-411: Is not the only time system based on an epoch and the Unix epoch is not the only epoch used by other time systems. Unix time differs from both Coordinated Universal Time (UTC) and International Atomic Time (TAI) in its handling of leap seconds . UTC includes leap seconds that adjust for the discrepancy between precise time, as measured by atomic clocks , and solar time , relating to the position of

1430-465: Is represented in Unix time as 31 536 000 . Negative values, on systems that support them, indicate times before the Unix epoch, with the value decreasing by 1 for every non-leap second before the epoch. For example, 00:00:00   UTC on 1 January 1969 is represented in Unix time as −31 536 000 . Every day in Unix time consists of exactly 86 400 seconds. Unix time is sometimes referred to as Epoch time . This can be misleading since Unix time

1485-463: 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

1540-573: Is used extensively in all modern desktop operating systems, including Microsoft Windows and Unix-like systems such as macOS and Linux , where it is a standard programming interface. iOS provides a Swift API which defaults to using an epoch of 1 January 2001 but can also be used with Unix timestamps. Android uses Unix time alongside a timezone for its system time API. Windows does not use Unix time for storing time internally but does use it in system APIs, which are provided in C++ and implement

1595-402: Is what happens across a positive leap second: 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

1650-554: The Active Directory Time Service and Server Message Block . The Network Time Protocol used to coordinate time between computers uses an epoch of 1 January 1900, counted in an unsigned 32-bit integer for seconds and another unsigned 32-bit integer for fractional seconds, which rolls over every 2 seconds (about once every 136 years). Many applications and programming languages provide methods for storing time with an explicit timezone. There are also

1705-564: 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,

X32 - Misplaced Pages Continue

1760-598: The x86 architecture , commonly incorrectly referred to as x32 (64-bit architecture is known as x64 ) [REDACTED] Topics referred to by the same term This disambiguation page lists articles associated with the same title formed as a letter–number combination. If an internal link led you here, you may wish to change the link to point directly to the intended article. Retrieved from " https://en.wikipedia.org/w/index.php?title=X32&oldid=1017724527 " Category : Letter–number combination disambiguation pages Hidden categories: Short description

1815-659: The 181.mcf SPEC CPU 2000 benchmark, in which the x32 ABI version was 40% faster than the x86-64 version. On average, x32 is 5–8% faster on the SPEC CPU integer benchmarks compared to x86-64. There is no speed advantage over x86-64 in the SPEC CPU floating-point benchmarks. There are also some application benchmarks that demonstrate the advantages of the x32 ABI. Running a userspace that consists mostly of programs compiled in ILP32 mode and which also have principal access to 64-bit CPU instructions has not been uncommon, especially in

1870-452: 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

1925-461: The C standard library specification. Unix time is used in the PE format for Windows executables. Unix time is typically available in major programming languages and is widely used in desktop, mobile, and web application programming. Java provides an Instant object which holds a Unix timestamp in both seconds and nanoseconds. Python provides a time library which uses Unix time. JavaScript provides

1980-459: The Earth's rotation) was used instead of an atomic timescale. 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

2035-730: 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. Unix time is widely adopted in computing beyond its original application as the system time for Unix . Unix time is available in almost all system programming APIs , including those provided by both Unix-based and non-Unix operating systems . Almost all modern programming languages provide APIs for working with Unix time or converting them to another data structure. Unix time

2090-449: 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

2145-510: The benefits of an x86-64 ABI with 32-bit pointers in the years since the Athlon 64 's release in 2003, notably Donald Knuth in 2008. There was little publicly visible progress towards implementing such a mode until August 27, 2011, when Hans Peter Anvin announced to the Linux kernel mailing list that he and H. J. Lu had been working on the x32 ABI. That same day, Linus Torvalds replied with

2200-407: The earth in relation to the sun. International Atomic Time (TAI), in which every day is precisely 86 400 seconds long, ignores solar time and gradually loses synchronization with the Earth's rotation at a rate of roughly one second per year. In Unix time, every day contains exactly 86 400 seconds. Each leap second uses the timestamp of a second that immediately precedes or follows it. On

2255-585: 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

X32 - Misplaced Pages Continue

2310-689: The epoch was 1970-01-01T00:00:00   TAI rather than 1970-01-01T00:00:10   TAI, was proposed for inclusion in ISO C's time.h , but only the UTC part was accepted in 2011. A tai_clock does, however, exist in C++20. 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

2365-419: 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, and firmly defined the Unix time in a simple manner in terms of

2420-531: The field of "classic RISC" chips. For example, the Solaris operating system does so for both SPARC and x86-64. On the Linux side, Debian also ships an ILP32 userspace. The underlying reason is the somewhat "more expensive" nature of LP64 code, just like it has been shown for x86-64. In that regard, the x32 ABI extends the ILP32-on-64bit concept to the x86-64 platform. Several people had discussed

2475-494: 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. The present form of UTC, with leap seconds, is defined only starting from 1 January 1972. Prior to that, since 1 January 1961 there

2530-434: 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

2585-412: 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 numbers are repeated in the second immediately following a positive leap second. The Unix time number 1 483 228 800 is thus ambiguous: it can refer either to start of

2640-399: The number of days is all that is significant to Unix time. The meaning of Unix time values below +63 072 000 (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

2695-512: The number of non- leap seconds that have elapsed since 00:00:00 UTC on 1 January 1970, the Unix epoch . For example, at midnight on January 1 2010, Unix time was 1262304000. Unix time originated as the system time of Unix operating systems. It has come to be widely used in other computer operating systems , file systems , programming languages , and databases . In modern computing, values are sometimes stored with higher granularity , such as microseconds or nanoseconds . Unix time

2750-456: The sample code available from the same source uses that information to convert between TAI-based timestamps 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 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, in which

2805-431: The underlying clock is fundamentally untroubled by leap seconds. Another, much rarer, non-conforming variant of Unix time keeping involves incrementing the value for all seconds, including leap seconds; some Linux systems are configured this way. Time kept in this fashion is sometimes referred to as "TAI" (although timestamps can be converted to UTC if the value corresponds to a time when the difference between TAI and UTC

SECTION 50

#1732771999242

2860-409: 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 86 400 . The quotient

2915-467: 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

2970-544: Was merged into the Linux kernel for the 3.4 release with support being added to the GNU C Library in version 2.16. In December 2018 there was discussion as to whether to deprecate the x32 ABI, which has not happened as of April 2023. Neither it has happened as of May 2024, and even more, it got some new development. Unix time Unix time is a date and time representation widely used in computing . It measures time by

3025-411: Was selected arbitrarily by Unix engineers because it was considered a convenient date to work with. The precision was changed to count in seconds in order to avoid short-term overflow. 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

#241758