5 ms·

This means that some time points cannot be represented by POSIX timestamps, and some POSIX timestamps do not correspond to any real time

marcosdumay 2y ago
Well, at least there isn't any POSIX timestamp that correspond to more than one real time point. So, it's better than the one representation people use for everything.
- brianpan 2y ago
  Not yet.
growse 2y ago
This has always been true. Pre 1970 is not defined in Unix time.
- usrnm 2y ago
  Why? time_t is signed
  - growse 2y ago
    From IEE 1003.1 (and TFA): > If year < 1970 or the value is negative, the relationship is undefined.
  - layer8 2y ago
    In addition to being formally undefined (see sibling comment), APIs sometimes use negative time_t values to indicate error conditions and the like.
  - 8n4vidtmkvmk 2y ago
    Probably because the Gregorian calendar didn't always exist. How do you map an int to a calendar that doesn't exist?
    - wahern 2y ago
      https://en.wikipedia.org/wiki/Proleptic_Gregorian_calendar https://en.wikipedia.org/wiki/Proleptic_Gregorian_calendar
  - _kst_ 2y ago
    Neither C nor POSIX requires time_t to be signed. The Open Group Base Specifications Issue 7, 2018 edition says that "time_t shall be an integer type". Issue 8, 2024 edition says "time_t shall be an integer type with a width of at least 64 bits". C merely says that time_t is a "real type capable of representing times". A "real type", as C defines the term, can be either integer or floating-point. It doesn't specify how time_t represents times; for example, a conforming implementation could represent 2024-12-27 02:17:31 UTC as 0x20241227021731. It's been suggested that time_t should be unsigned so a 32-bit integer can represent times after 2038 (at the cost of not being able to represent times before 1970). Fortunately this did not catch on, and with the current POSIX requiring 64 bits, it wouldn't make much sense. But the relevant standards don't forbid an unsigned time_t.
    - _kst_ 2y ago
      Apparently both Pelles C for Windows and VAX/VMS use a 32-bit unsigned time_t.
- deepsun 2y ago
  Related question that leads too deep: "What was before the Big Bang?"
GolDDranks 2y ago
What are POSIX timestamps that don't correspond to any real time? Or do you mean in the future if there is a negative leap second?
- schneehertz 2y ago
  Yes, negative leap seconds are possible in the future if leap second adjustments are not abandoned
paulddraper 2y ago
No. That'd be like saying some points in time that don't have a ISO 8601 year. Every point in time has a year, but some years are longer than others. If you sat down and watched https://time.is/UTC https://time.is/UTC, it would monotonically tick up, except that occasionally some seconds would be very slightly longer. Like 0.001% longer over the course of 24 hours.
- schneehertz 2y ago
  The positive leap second of UTC is inserted at midnight, resulting in 86,401 seconds on that day. Reference: https://en.wikipedia.org/wiki/Leap_second https://en.wikipedia.org/wiki/Leap_second

marcosdumay 2y ago

Well, at least there isn't any POSIX timestamp that correspond to more than one real time point. So, it's better than the one representation people use for everything.

brianpan 2y ago
Not yet.

growse 2y ago

This has always been true. Pre 1970 is not defined in Unix time.

usrnm 2y ago
Why? time_t is signed
- growse 2y ago
  From IEE 1003.1 (and TFA): > If year < 1970 or the value is negative, the relationship is undefined.
- layer8 2y ago
  In addition to being formally undefined (see sibling comment), APIs sometimes use negative time_t values to indicate error conditions and the like.
- 8n4vidtmkvmk 2y ago
  Probably because the Gregorian calendar didn't always exist. How do you map an int to a calendar that doesn't exist?
  - wahern 2y ago
    https://en.wikipedia.org/wiki/Proleptic_Gregorian_calendar https://en.wikipedia.org/wiki/Proleptic_Gregorian_calendar
- _kst_ 2y ago
  Neither C nor POSIX requires time_t to be signed. The Open Group Base Specifications Issue 7, 2018 edition says that "time_t shall be an integer type". Issue 8, 2024 edition says "time_t shall be an integer type with a width of at least 64 bits". C merely says that time_t is a "real type capable of representing times". A "real type", as C defines the term, can be either integer or floating-point. It doesn't specify how time_t represents times; for example, a conforming implementation could represent 2024-12-27 02:17:31 UTC as 0x20241227021731. It's been suggested that time_t should be unsigned so a 32-bit integer can represent times after 2038 (at the cost of not being able to represent times before 1970). Fortunately this did not catch on, and with the current POSIX requiring 64 bits, it wouldn't make much sense. But the relevant standards don't forbid an unsigned time_t.
  - _kst_ 2y ago
    Apparently both Pelles C for Windows and VAX/VMS use a 32-bit unsigned time_t.
deepsun 2y ago
Related question that leads too deep: "What was before the Big Bang?"

GolDDranks 2y ago

What are POSIX timestamps that don't correspond to any real time? Or do you mean in the future if there is a negative leap second?

schneehertz 2y ago
Yes, negative leap seconds are possible in the future if leap second adjustments are not abandoned

paulddraper 2y ago

No. That'd be like saying some points in time that don't have a ISO 8601 year. Every point in time has a year, but some years are longer than others. If you sat down and watched https://time.is/UTC https://time.is/UTC, it would monotonically tick up, except that occasionally some seconds would be very slightly longer. Like 0.001% longer over the course of 24 hours.

schneehertz 2y ago
The positive leap second of UTC is inserted at midnight, resulting in 86,401 seconds on that day. Reference: https://en.wikipedia.org/wiki/Leap_second https://en.wikipedia.org/wiki/Leap_second