System time is measured by a system clock, which is typically implemented as a simple count of the number of ticks that have transpired since some arbitrary starting date, called the epoch. For example, Unix and POSIX-compliant systems encode system time ("Unix time") as the number of seconds elapsed since the start of the Unix epoch at 1 January 1970 00:00:00 UT, with exceptions for leap seconds. Systems that implement the 32-bit and 64-bit versions of the Windows API, such as Windows 9x and Windows NT, provide the system time as both SYSTEMTIME, represented as a year/month/day/hour/minute/second/milliseconds value, and FILETIME, represented as a count of the number of 100-nanosecond ticks since 1 January 1601 00:00:00 UT as reckoned in the proleptic Gregorian calendar.
System time can be converted into calendar time, which is a form more suitable for human comprehension. For example, the Unix system time1000000000 seconds since the beginning of the epoch translates into the calendar time 9 September 2001 01:46:40 UT. Library subroutines that handle such conversions may also deal with adjustments for time zones, daylight saving time (DST), leap seconds, and the user's locale settings. Library routines are also generally provided that convert calendar times into system times.
Many implementations that currently store system times as 32-bit integer values will suffer from the impending Year 2038 problem. These time values will overflow ("run out of bits") after the end of their system time epoch, leading to software and hardware errors. These systems will require some form of remediation, similar to efforts required to solve the earlier Year 2000 problem. This will also be a potentially much larger problem for existing data file formats that contain system timestamps stored as 32-bit values.
Other time measurements
Closely related to system time is process time, which is a count of the total CPU time consumed by an executing process. It may be split into user and system CPU time, representing the time spent executing user code and system kernel code, respectively. Process times are a tally of CPU instructions or clock cycles and generally have no direct correlation to wall time.
Most first-generation personal computers did not keep track of dates and times. These included systems that ran the CP/M operating system, as well as early models of the Apple II, the BBC Micro, and the Commodore PET, among others. Add-on peripheral boards that included real-time clock chips with on-board battery back-up were available for the IBM PC and XT, but the IBM AT was the first widely available PC that came equipped with date/time hardware built into the motherboard. Prior to the widespread availability of computer networks, most personal computer systems that did track system time did so only with respect to local time and did not make allowances for different time zones.
Microcontrollers operating within embedded systems (such as the Raspberry Pi, Arduino, and other similar systems) do not always have internal hardware to keep track of time. Many such controller systems operate without knowledge of the external time. Those that require such information typically initialize their base time upon rebooting by obtaining the current time from an external source, such as from a time server or external clock, or by prompting the user to manually enter the current time.
Implementation
The system clock is typically implemented as a programmable interval timer that periodically interrupts the CPU, which then starts executing a timer interrupt service routine. This routine typically adds one tick to the system clock (a simple counter) and handles other periodic housekeeping tasks (preemption, etc.) before returning to the task the CPU was executing before the interruption.
The resolution of an implementation's measurement of time does not imply the same precision of such measurements. For example, a system might return the current time as a value measured in microseconds, but actually be capable of discerning individual clock ticks with a frequency of only 100 Hz (10 ms).
^ abThe Apple Developer Documentation is not clear on the precision & range of CFAbsoluteTime/CFTimeInterval, except in the CFRunLoopTimerCreate documentation which refers to 'sub-millisecond at most' precision. However, the similar type NSTimeInterval appears to be interchangeable, and has the precision and range listed.
^ abcdThe C standard library does not specify any specific resolution, epoch, range, or datatype for system time values. The C++ library encompasses the C library, so it uses the same system time implementation as C.
^IBM intends to extend the date range on future systems beyond 2042. z/Architecture Principles of Operation, (Poughkeepsie, New York:International Business Machines, 2007) 1-15, 4-45 to 4-47.
^Jonathan de Boyne Pollard. "The 32-bit Command Interpreter". On OS/2 Warp 4, date and time can both operate well beyond the year 2000, and even well beyond the year 2038, and in fact up to the year 2079, which is the limit for OS/2 Warp 4's real-time clock.
^"XL2000: Early Dates on Office Spreadsheet Component Differ from Excel". Microsoft Support. 2003. Archived from the original on 24 October 2007. In the Microsoft Office Spreadsheet Component, the value 0 evaluates to the date December 30, 1899 and the value 1 evaluates to December 31, 1899. ... In Excel, the value 0 evaluates to January 0, 1900 and the value 1 evaluates to January 1, 1900.
^"SYSTEM_CLOCK". Intel Fortran Compiler 19.0 Developer Guide and Reference. 29 April 2019. Retrieved 23 July 2019.
^Douglas Wegscheild, R. Schertler, and Jarkko Hietaniemi, "Time::HiRes". CPAN - Comprehensive Perl Archive Network. 2011. Retrieved 27 October 2011.
^James Britt; Neurogami. "Time class". Ruby-Doc.org: Help and documentation for the Ruby programming language. Scottsdale, AZ. Retrieved 27 October 2011.
^Yugui (18 August 2010). "Ruby 1.9.2 is released". The new 1.9.2 is almost compatible with 1.9.1, except these changes: ... Time is reimplemented. The bug with year 2038 is fixed.
