POSIX

The Portable Operating System Interface (POSIX)[1] is a family of standards specified by the IEEE Computer Society for maintaining compatibility between operating systems. POSIX defines the application programming interface (API), along with command line shells and utility interfaces, for software compatibility with variants of Unix and other operating systems.[2][3]

Name

Originally, the name "POSIX" referred to IEEE Std 1003.1-1988, released in 1988. The family of POSIX standards is formally designated as IEEE 1003 and the international standard name is ISO/IEC 9945.

The standards emerged from a project that began circa 1985. Richard Stallman suggested the name POSIX to the IEEE instead of former IEEE-IX. The committee found it more easily pronounceable and memorable, and thus adopted it.[2][4]

Overview

Unix was selected as the basis for a standard system interface partly because it was "manufacturer-neutral". However, several major versions of Unix existed—so there was a need to develop a common denominator system. The POSIX specifications for Unix-like operating systems originally consisted of a single document for the core programming interface, but eventually grew to 19 separate documents (POSIX.1, POSIX.2, etc.).[5] The standardized user command line and scripting interface were based on the UNIX System V shell.[6] Many user-level programs, services, and utilities (including awk, echo, ed) were also standardized, along with required program-level services (including basic I/O: file, terminal, and network). POSIX also defines a standard threading library API which is supported by most modern operating systems. In 2008, most parts of POSIX were combined into a single standard (IEEE Std 1003.1-2008, also known as POSIX.1-2008).

As of 2014, POSIX documentation is divided into two parts:

  • POSIX.1, 2013 Edition: POSIX Base Definitions, System Interfaces, and Commands and Utilities (which include POSIX.1, extensions for POSIX.1, Real-time Services, Threads Interface, Real-time Extensions, Security Interface, Network File Access and Network Process-to-Process Communications, User Portability Extensions, Corrections and Extensions, Protection and Control Utilities and Batch System Utilities. This is POSIX 1003.1-2008 with Technical Corrigendum 1.)
  • POSIX Conformance Testing: A test suite for POSIX accompanies the standard: VSX-PCTS or the VSX POSIX Conformance Test Suite.[7]

The development of the POSIX standard takes place in the Austin Group (a joint working group linking the IEEE, The Open Group and the ISO/IEC JTC 1 organizations).

Versions

Parts before 1997

Before 1997, POSIX comprised several standards:

Versions after 1997

After 1997, the Austin Group developed the POSIX revisions. The specifications are known under the name Single UNIX Specification, before they become a POSIX standard when formally approved by the ISO.

POSIX.1-2001

POSIX.1-2001 (or IEEE Std 1003.1-2001) equates to the Single UNIX Specification version 3.[9]

This standard consisted of:

  • the Base Definitions, Issue 6,
  • the System Interfaces and Headers, Issue 6,
  • the Commands and Utilities, Issue 6.

POSIX.1-2004 (with two TCs)

IEEE Std 1003.1-2004 involved a minor update of POSIX.1-2001. It incorporated two minor updates or errata referred to as Technical Corrigenda (TCs).[10] Its contents are available on the web.[11]

POSIX.1-2008 (with two TCs)

Base Specifications, Issue 7 (or IEEE Std 1003.1-2008, 2016 Edition) is similar to the current 2017 version (as of 22.7.2018).[12][13] A free online copy may still be available.[12]

This standard consists of:

  • the Base Definitions, Issue 7,
  • the System Interfaces and Headers, Issue 7,
  • the Commands and Utilities, Issue 7,
  • the Rationale volume.

POSIX.1-2017

IEEE Std 1003.1-2017 (Revision of IEEE Std 1003.1-2008) - IEEE Standard for Information Technology--Portable Operating System Interface (POSIX(R)) Base Specifications, Issue 7 is available from either The Open Group or IEEE and is, as of 22.7.2018, the current standard.

Controversies

512- vs 1024-byte blocks

POSIX mandates 512-byte default block sizes for the df and du utilities, reflecting the typical size of blocks on disks. When Richard Stallman and the GNU team were implementing POSIX for the GNU operating system, they objected to this on the grounds that most people think in terms of 1024 byte (or 1 KiB) blocks. The environment variable POSIX_ME_HARDER was introduced to allow the user to force the standards-compliant behaviour.[14] The variable name was later changed to POSIXLY_CORRECT.[15] This variable is now also used for a number of other behaviour quirks, where "POSIX and common sense disagree".

POSIX-oriented operating systems

Depending upon the degree of compliance with the standards, one can classify operating systems as fully or partly POSIX compatible. Certified products can be found at the IEEE's website.[16]

POSIX-certified

Some versions of the following operating systems have been certified to conform to one or more of the various POSIX standards. This means that they passed the automated conformance tests.[17]

Mostly POSIX-compliant

The following, while not officially certified as POSIX compatible, comply in large part:

POSIX for Microsoft Windows

  • Cygwin provides a largely POSIX-compliant development and run-time environment for Microsoft Windows.
  • MinGW, a fork of Cygwin, provides a less POSIX-compliant development environment and supports compatible C-programmed applications via Msvcrt, Microsoft's old Visual C runtime library.
  • Microsoft POSIX subsystem, an optional Windows subsystem included in Windows NT-based operating systems up to Windows 2000. POSIX-1 as it stood in 1990 revision, without threads or sockets.
  • Interix, originally OpenNT by Softway Systems, Inc., is an upgrade and replacement for Microsoft POSIX subsystem that was purchased by Microsoft in 1999. It was initially marketed as a stand-alone add-on product and then later included it as a component in Windows Services for UNIX (SFU) and finally incorporated it as a component in Windows Server 2003 R2 and later Windows OS releases under the name "Subsystem for UNIX-based Applications" (SUA); later made deprecated in 2012 (Windows 8)[32] and dropped in 2013 (2012 R2, 8.1). It enables full POSIX compliance for certain Microsoft Windows products.
  • Windows Subsystem for Linux is a compatibility layer for running Linux binary executables natively on Windows 10 using an Ubuntu image, acting as an upgrade and replacement for Windows Services for UNIX. It was released in beta in April 2016.
  • UWIN from AT&T Research implements a POSIX layer on top of the Win32 APIs.
  • MKS Toolkit, originally created for MS-DOS, is a software package produced and maintained by MKS Inc. that provides a Unix-like environment for scripting, connectivity and porting Unix and Linux software to both 32- and 64-bit Microsoft Windows systems. A subset of it was included in the first release of Windows Services for UNIX (SFU) in 1998.[33]
  • Windows C Runtime Library and Windows Sockets API implement commonly used POSIX API functions for file, time, environment, and socket access,[34] although the support remains largely incomplete and not fully interoperable with POSIX-compliant implementations.[35][36]

POSIX for OS/2

Mostly POSIX compliant environments for OS/2:

  • emx+gcc – largely POSIX compliant

POSIX for DOS

Partially POSIX compliant environments for DOS include:

  • emx+gcc – largely POSIX compliant
  • DJGPP – partially POSIX compliant
  • DR-DOS multitasking core via EMM386 /MULTI – a POSIX threads frontend API extension is available

Compliant via compatibility feature

The following are not officially certified as POSIX compatible, but they conform in large part to the standards by implementing POSIX support via some sort of compatibility feature (usually translation libraries, or a layer atop the kernel). Without these features, they are usually noncompliant.

See also

References

  1. ^ "POSIX.1 FAQ". The Open Group. 5 October 2011.
  2. ^ a b "POSIX 1003.1 FAQ Version 1.12". 2 February 2006. Retrieved 16 July 2006.
  3. ^ "POSIX". Standards. IEEE.
  4. ^ "The origin of the name POSIX". 2011. Retrieved 28 September 2013.
  5. ^ PASC Status (including POSIX) (Report). IEEE Computer Society. 2003-12-04. Retrieved 2015-03-01.
  6. ^ "Shell Command Language - The Open Group Base Specifications Issue 7, 2013 Edition".
  7. ^ "POSIX". The Open Group.
  8. ^ "librt(3LIB)". docs.oracle.com. man pages section 3: Library Interfaces and Headers. Oracle Corporation. 1998-08-04. Retrieved 2016-02-18. librt, libposix4- POSIX.1b Realtime Extensions library [...] librt is the preferred name for this library. The name libposix4 is maintained for backward compatibility and should be avoided. Functions in this library provide most of the interfaces specified by the POSIX.1b Realtime Extension.
  9. ^ "The Open Group announces completion of the joint revision to POSIX and the Single UNIX Specification" (Press release). The Open Group. 30 January 2002. Retrieved 26 July 2009.
  10. ^ "IEEE Std 1003.1" (2004 ed.). Unix.org. Retrieved 26 July 2009
  11. ^ "IEEE Std 1003.1" (2004 ed.). The Open Group.
  12. ^ a b "Base Specifications, Issue 7, 2016 Edition". The Open Group. Retrieved 18 December 2014.
  13. ^ "The Austin Common Standards Revision Group". The Open Group. Retrieved 1 March 2016.
  14. ^ "Announce" (Google Groups replica). GNU.
  15. ^ "GNU Coding Standards". GNU.
  16. ^ "POSIX Certification". IEEE.
  17. ^ "POSIX Certified by IEEE and The Open Group - Program Guide".
  18. ^ "IBM". The Open Group. Retrieved 26 January 2014.
  19. ^ a b "Hewlett-Packard". The Open Group. Retrieved 26 January 2014.
  20. ^ "Silicon Graphics, Inc". The Open Group. Retrieved 26 January 2014.
  21. ^ "Huawei Technology Co., Ltd". The Open Group. Retrieved 26 May 2017.
  22. ^ "The Open Brand - Register of Certified Products". Register of Open Branded Products. The Open Group. Retrieved 20 May 2015.
  23. ^ "Apple Inc". Register of Open Branded Products. The Open Group. Retrieved 20 May 2015.
  24. ^ "Oracle Corporation". The Open Group. Retrieved 26 January 2014.
  25. ^ "UnixWare ® 7.1.3 and later". The Open Group. 16 May 2003.
  26. ^ "QNX Achieves New POSIX Certification". QNX. 8 April 2008. Retrieved 16 January 2016.
  27. ^ "Inspur Co., Ltd". The Open Group. Retrieved 26 May 2017.
  28. ^ "POSIX Certification Register". get.posixcertified.ieee.org. Retrieved 2018-03-09.
  29. ^ Schweik. "POSIX utilities". FreeBSD.
  30. ^ Enterprise, I. D. G. (1994-11-07). Computerworld. IDG Enterprise.
  31. ^ Solter, Nicholas A.; Jelinek, Jerry; Miner, David (2011-03-21). OpenSolaris Bible. John Wiley & Sons. ISBN 9781118080313.
  32. ^ Features Removed or Deprecated in Windows Server 2012
  33. ^ Windows NT Services for UNIX Add-On Pack for NT 4; see also the November '98 press release for MKS toolkit 6.1, also archived elsewhere
  34. ^ "MSDN Library: Deprecated CRT Functions". Microsoft. Retrieved 8 Oct 2015.
  35. ^ "MSDN Library: Porting Socket Applications to Winsock". Microsoft. Retrieved 8 Oct 2015.
  36. ^ "Winsock Programmer's FAQ Articles: BSD Sockets Compatibility". Warren Young. 31 Aug 2015. Retrieved 8 Oct 2015.
  37. ^ "APE — ANSI/POSIX Environment". Plan 9. Bell Labs.
  38. ^ "POSIX Compatibility". MS Windows NT Workstation Resource Kit. Microsoft.

External links

Application programming interface

In computer programming, an application programming interface (API) is a set of subroutine definitions, communication protocols, and tools for building software. In general terms, it is a set of clearly defined methods of communication among various components. A good API makes it easier to develop a computer program by providing all the building blocks, which are then put together by the programmer.

An API may be for a web-based system, operating system, database system, computer hardware, or software library.

An API specification can take many forms, but often includes specifications for routines, data structures, object classes, variables, or remote calls. POSIX, Windows API and ASPI are examples of different forms of APIs. Documentation for the API usually is provided to facilitate usage and implementation.

Bc (programming language)

bc, for basic calculator (often referred to as bench calculator), is "an arbitrary-precision calculator language" with syntax similar to the C programming language. bc is typically used as either a mathematical scripting language or as an interactive mathematical shell.

C POSIX library

The C POSIX library is a specification of a C standard library for POSIX systems. It was developed at the same time as the ANSI C standard. Some effort was made to make POSIX compatible with standard C; POSIX includes additional functions to those introduced in standard C.

Cksum

cksum is a command in Unix-like operating systems that generates a checksum value for a file or stream of data. The cksum command reads each file given in its arguments, or standard input if no arguments are provided, and outputs the file's CRC checksum and byte count.

The cksum command can be used to verify that files transferred by unreliable means arrived intact. However, the CRC checksum calculated by the cksum command is not cryptographically secure: While it guards against accidental corruption (it is unlikely that the corrupted data will have the same checksum as the intended data), it is not difficult for an attacker to deliberately corrupt the file in a specific way that its checksum is unchanged. Unix-like systems typically include other commands for cryptographically secure checksums, such as sha256sum.

Comparison of operating systems

These tables provide a comparison of operating systems, of computer devices, as listing general and technical information for a number of widely used and currently available PC or handheld (including smartphone and tablet computer) operating systems. The article "Usage share of operating systems" provides a broader, and more general, comparison of operating systems that includes servers, mainframes and supercomputers.

Because of the large number and variety of available Linux distributions, they are all grouped under a single entry; see comparison of Linux distributions for a detailed comparison. There is also a variety of BSD and DOS operating systems, covered in comparison of BSD operating systems and comparison of DOS operating systems. For information on views of each operating system, see operating system advocacy.

Cygwin

Cygwin ( SIG-win) is a POSIX-compatible environment that runs natively on Microsoft Windows. Its goal is to allow programs of Unix-like systems to be recompiled and run natively on Windows with minimal source code modifications by providing them with the same underlying POSIX API they would expect in those systems.

The Cygwin installation directory behaves like the root and follows a similar directory layout to that found in Unix-like systems, with familiar directories like /bin, /home, /etc, /usr, /var available within it, and includes by default hundreds of programs and command-line tools commonly found in the Unix world, plus the terminal emulator Mintty which is the default command-line interface tool provided to interact with the environment.

Cygwin provides native integration of Windows-based applications, data, and other system resources with applications, software tools, and data of the Unix-like environment. Thus it is possible to launch Windows applications from the Cygwin environment, as well as to use Cygwin tools and applications within the Windows operating context.

Cygwin consists of two parts: a dynamic-link library (DLL) as an API compatibility layer in the form of a C standard library providing a substantial part of the POSIX API functionality, and an extensive collection of software tools and applications that provide a Unix-like look and feel.

Cygwin was originally developed by Cygnus Solutions, which was later acquired by Red Hat, to port the Gnu/Linux toolchain to Win32, including the GNU Compiler Suite. Rather than rewrite all the tools to use Win32 runtimes, Cygwin implemented a POSIX compatible runtime as a DLL. It is free and open-source software, released under the GNU Lesser General Public License version 3. Today it is maintained by employees of Red Hat, NetApp and many other volunteers.

ISO/IEC 15897

ISO/IEC 15897 (Procedures for the registration of cultural elements) is an ISO standard for the registration of new POSIX locales and POSIX charmaps. This standard is the result of a "fast-track" adoption of CEN ENV 12005, a European prestandard published by CEN. It was originally published in 1999, and a second edition was published in 2011.

The standard was produced by Working Group 20 (WG20) of the JTC/1 SC22 committee, but in 2006 the standard was transferred to the JTC/1 SC35 committee. The registry is maintained by Danish UNIX-systems User Group (DKUUG), although it has not been updated since December 2001. The standard was confirmed in 2017, following a five-yearly systematic review.Items registered in the registry are:

Narrative Cultural Specifications

POSIX Locales

POSIX Charmaps

RepertoiremapsIt overlaps somewhat with the CLDR project hosted at the Unicode Consortium.

Kazehakase

Kazehakase (Japanese: Dr. Wind (風博士, kaze hakase)) was a web browser for Unix-like operating systems that uses the GTK+ libraries. Kazehakase embeds the Gecko layout engine as well as GTK+ WebKit.

The browser is named after the short story "Kazehakase" by the Japanese author Ango Sakaguchi; its literal meaning is "Dr. Wind" (a PhD rather than a medical doctor).

Microsoft POSIX subsystem

Microsoft POSIX subsystem is one of four subsystems shipped with the first versions of Windows NT. (The other three being the Win32 subsystem which provided the primary programming API for Windows NT, plus the OS/2 and security subsystems.)

This subsystem implements only the POSIX.1 standard — also known as IEEE Std 1003.1-1990 or ISO/IEC 9945-1:1990 — primarily covering the kernel and C library programming interfaces which allowed a program written for other POSIX.1-compliant operating systems to be compiled and run under Windows NT. The Windows NT POSIX subsystem did not provide the interactive user environment parts of POSIX, originally standardized as POSIX.2. That is, Windows NT did not provide a POSIX shell nor any Unix commands like ls. The NT POSIX subsystem also did not provide any of the POSIX extensions that postdated the creation of Windows NT 3.1, such as those for POSIX Threads or POSIX IPC.

The NT POSIX subsystem was included with the first versions of Windows NT because of 1980s US federal government requirements listed in Federal Information Processing Standard (FIPS) 151-2. Briefly, these documents required that certain types of government purchases be POSIX-compliant, so that if Windows NT had not included this subsystem, computing systems based on it would not have been eligible for some government contracts. Windows NT versions 3.5, 3.51 and 4.0 were certified as compliant with FIPS 151-2.

The runtime environment of the subsystem is provided by two files: psxss.exe and psxdll.dll. A POSIX application uses psxdll.dll to communicate with the subsystem while communicating with posix.exe to provide display capabilities on the Windows desktop.

The POSIX subsystem was replaced in Windows XP / Windows Server 2003 by "Windows Services for UNIX", (SFU) which is based in part on technology Microsoft acquired by buying Interix. SFU was removed from later versions of Windows 8 and Windows Server 2012. (See prior link.) SFU is logically (though not formally) replaced by the Windows Subsystem for Linux (WSL) in the Windows 10 Anniversary Update and Windows Server 2016 Version 1709 respectively.

POSIX Threads

POSIX Threads, usually referred to as pthreads, is an execution model that exists independently from a language, as well as a parallel execution model. It allows a program to control multiple different flows of work that overlap in time. Each flow of work is referred to as a thread, and creation and control over these flows is achieved by making calls to the POSIX Threads API. POSIX Threads is an API defined by the standard POSIX.1c, Threads extensions (IEEE Std 1003.1c-1995).

Implementations of the API are available on many Unix-like POSIX-conformant operating systems such as FreeBSD, NetBSD, OpenBSD, Linux, Mac OS X, Android, Solaris and AUTOSAR Adaptive, typically bundled as a library libpthread. DR-DOS and Microsoft Windows implementations also exist: within the SFU/SUA subsystem which provides a native implementation of a number of POSIX APIs, and also within third-party packages such as pthreads-w32, which implements pthreads on top of existing Windows API.

Read (system call)

In modern POSIX compliant operating systems, a program that needs to access data from a file stored in a file system uses the read system call. The file is identified by a file descriptor that is normally obtained from a previous call to open. This system call reads in data in bytes, the number of which is specified by the caller, from the file and stores then into a buffer supplied by the calling process.

The read system call takes three arguments:

The file descriptor of the file.

the buffer where the read data is to be stored and

the number of bytes to be read from the file.

Regular expression

A regular expression, regex or regexp (sometimes called a rational expression) is a sequence of characters that define a search pattern. Usually this pattern is used by string searching algorithms for "find" or "find and replace" operations on strings, or for input validation. It is a technique that developed in theoretical computer science and formal language theory.

The concept arose in the 1950s when the American mathematician Stephen Cole Kleene formalized the description of a regular language. The concept came into common use with Unix text-processing utilities. Since the 1980s, different syntaxes for writing regular expressions exist, one being the POSIX standard and another, widely used, being the Perl syntax.

Regular expressions are used in search engines, search and replace dialogs of word processors and text editors, in text processing utilities such as sed and AWK and in lexical analysis. Many programming languages provide regex capabilities, built-in or via libraries.

Signal (IPC)

Signals are a limited form of inter-process communication (IPC), typically used in Unix, Unix-like, and other POSIX-compliant operating systems. A signal is an asynchronous notification sent to a process or to a specific thread within the same process in order to notify it of an event that occurred. Signals originated in 1970s Bell Labs Unix and have been more recently specified in the POSIX standard.

When a signal is sent, the operating system interrupts the target process' normal flow of execution to deliver the signal. Execution can be interrupted during any non-atomic instruction. If the process has previously registered a signal handler, that routine is executed. Otherwise, the default signal handler is executed.

Embedded programs may find signals useful for interprocess communications, as the computational and memory footprint for signals is small.

Signals are similar to interrupts, the difference being that interrupts are mediated by the processor and handled by the kernel while signals are mediated by the kernel (possibly via system calls) and handled by processes. The kernel may pass an interrupt as a signal to the process that caused it (typical examples are SIGSEGV, SIGBUS, SIGILL and SIGFPE).

Single UNIX Specification

The Single UNIX Specification (SUS) is the collective name of a family of standards for computer operating systems, compliance with which is required to qualify for using the "UNIX" trademark. The core specifications of the SUS are developed and maintained by the Austin Group, which is a joint working group of IEEE, ISO JTC 1 SC22 and The Open Group. If an operating system is submitted to The Open Group for certification, and passes conformance tests, then it is deemed to be compliant with a UNIX standard such as UNIX 98 or UNIX 03.

Very few BSD and Linux-based operating systems are submitted for compliance with the Single UNIX Specification, although system developers generally aim for compliance with POSIX standards, which form the core of the Single UNIX Specification.

Tar (computing)

In computing, tar is a computer software utility for collecting many files into one archive file, often referred to as a tarball, for distribution or backup purposes. The name is derived from (t)ape (ar)chive, as it was originally developed to write data to sequential I/O devices with no file system of their own. The archive data sets created by tar contain various file system parameters, such as name, time stamps, ownership, file access permissions, and directory organization. The command line utility was first introduced in the Version 7 Unix in January 1979, replacing the tp program. The file structure to store this information was standardized in POSIX.1-1988 and later POSIX.1-2001, and became a format supported by most modern file archiving systems.

Unix domain socket

A Unix domain socket or IPC socket (inter-process communication socket) is a data communications endpoint for exchanging data between processes executing on the same host operating system. Valid socket types in the UNIX domain are: SOCK_STREAM (compare to TCP), for a stream-oriented socket; SOCK_DGRAM (compare to UDP), for a datagram-oriented socket that preserves message boundaries (as on most UNIX implementations, UNIX domain datagram sockets are always reliable and don't reorder datagrams); and SOCK_SEQPACKET (compare to SCTP), for a sequenced-packet socket that is connection-oriented, preserves message boundaries, and delivers messages in the order that they were sent. The Unix domain socket facility is a standard component of POSIX operating systems.

The API for Unix domain sockets is similar to that of an Internet socket, but rather than using an underlying network protocol, all communication occurs entirely within the operating system kernel. Unix domain sockets use the file system as their address name space. Processes reference Unix domain sockets as file system inodes, so two processes can communicate by opening the same socket.

In addition to sending data, processes may send file descriptors across a Unix domain socket connection using the sendmsg() and recvmsg() system calls. This allows the sending processes to grant the receiving process access to a file descriptor for which the receiving process otherwise does not have access. This can be used to implement a rudimentary form of capability-based security. For example, this allows the Clam AntiVirus scanner to run as an unprivileged daemon on Linux and BSD, yet still read any file sent to the daemon's Unix domain socket.

Unix shell

A Unix shell is a command-line interpreter or shell that provides a command line user interface for Unix-like operating systems. The shell is both an interactive command language and a scripting language, and is used by the operating system to control the execution of the system using shell scripts.Users typically interact with a Unix shell using a terminal emulator; however, direct operation via serial hardware connections or Secure Shell are common for server systems. All Unix shells provide filename wildcarding, piping, here documents, command substitution, variables and control structures for condition-testing and iteration.

Unix time

Unix time (also known as POSIX time or UNIX Epoch time) 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, Coordinated Universal Time (UTC), minus leap seconds. Every day is treated as if it contains exactly 86400 seconds, so leap seconds are to be subtracted since the epoch. 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.

On systems where Unix time is stored as a signed 32-bit number, 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.

Standards by The Open Group
ISO standards by standard number
1–9999
10000–19999
20000+
IEC standards
ISO/IEC standards
Related

This page is based on a Wikipedia article written by authors (here).
Text is available under the CC BY-SA 3.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.