5 ms·

You would then lose the ability to represent times before Jan. 1st, 1970. Which is not just a theoretical concern; those times appear e.g. in databases with peo

You would then lose the ability to represent times before Jan. 1st, 1970. Which is not just a theoretical concern; those times appear e.g. in databases with people's date of birth.

nobluster 2y ago
And a signed 32 bit time_t with an epoch of 1970 cannot represent dates before 1902. Using time_t to store legacy dates is not advisable - even if you ignore all the issues with time zones and changing local laws pertaining to offsets from UTC and daylight saving time.
- pwg 2y ago
  While true, that limitation has always existed, so everyone has already implemented whatever was necessary to represent dates earlier than that. Changing 32-bit time_t to unsigned suddenly makes all dates from 1902 to Jan 1 1970 which were stored using time_t (even if it was non-advisable, it still will have occurred) appear to teleport into the future beyond 2038.
  - cryptonector 2y ago
    That's alright, see, because I have no filesystems, no tarballs, no backups, no files on any kind of media with timestamps before 1970, and indeed, no one can except by manually setting those timestamps -- and why bother doing that?! So any pre-1970 32-bit signed timestamps will be in... not spreadsheets, in what? In databases? No, not either. So in some sort of documents, so software consuming those will need fixing, but we're not going to see much teleporting of 1902-1970 timestamps to 2038-2106. I'm not concerned.
    - jasomill 2y ago
      Many important software projects predate UNIX. Perhaps you want to create a Git repository for one of them, with historically accurate commit timestamps?
      - loeg 2y ago
        Git represents timestamps in ASCII strings, like "12345." Not time_t. (I am not sure if it even allows negative integers in this format.)
        jasomill 2y ago
        I was just using Git as an example of an application where pre-1970 timestamps could be useful. But as it turns out, $ git commit -m foo --date='1969-12-31 00:00:00' [main 25b6e63] foo Date: Sun Dec 30 23:00:00 2012 -0500 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 bar
      - cryptonector 2y ago
        Well, Git doesn't seem to set file timestamps when cloning. And as the sibling comment says, Git doesn't use 32-bit signed integers to store timestamps. So this is not a problem. If, however, Git were to some day get an option to set file mtimes and atimes at clone time to the last-modified time of the files based on commit history, then you could always just use a 64-bit system where `time_t` is 64-bit.
        account42 2y ago
        > Well, Git doesn't seem to set file timestamps when cloning. This is intentional btw because otherwise with many build system things would not get rebuilt correctly when checking out an older snapshot.
      - cesarb 2y ago
        More importantly than a git repository, you might have archives (a .tar or equivalent) of these software projects, and might want to unpack them while preserving the timestamps contained within these archives.
        cryptonector 2y ago
        Unix did not exist before 1970. Neither did tar. There are no tar files with files with timestamps before 1970 _unless_ you've used `touch -t 195001010000` or `utime(2)` or `futimes(3)` to set the files' time to before 1970. That seems pretty unlikely.
bloak 2y ago
Serious question: do people use time_t for representing a date of birth? To me that wouldn't seem right: a date of birth isn't a timestamp and you typically receive it without a corresponding place or time zone so there's no reasonable way to convert it into a timestamp. (The other problem is that a signed 32-bit time_t only goes back to 1901. You might not have to deal with a date of birth before 1901 today, unless you're doing genealogy, of course, but until fairly recently it's something you'd probably want to be able to handle.)
- nomel 2y ago
  My birth certificate has location, day, year, hour, and minute of birth. Birth is an event in time, perfectly represented with a (UTC) timestamp.
  - Merad 2y ago
    Your birth is an event that happened at an instant in time, but very few systems concern themselves with that detail. The vast majority need to store birth _date_ and have no interest in the time or location.
    - nomel 2y ago
      > have no interest in the time Setting the bottom couple of bytes to zero achieves this, while maintaining nearly universal consistency with all other events in time that might need to be related with a packing of bits. People do it because it's what's being used at nearly every other level of the stack.
  - cryptonector 2y ago
    > Birth is an event in time, perfectly represented with a (UTC) timestamp. That's not the same thing as `time_t` though. `time_t` is UTC. UTC is not `time_t`.
- School-Cotton 2y ago
  > Serious question: do people use time_t for representing a date of birth? I have seen people in real life use seconds since the UNIX epoch to represent DOB, yes.
loeg 2y ago
Databases do not and can not use system time_t. Consider how their on-disk state would be impacted by a change from 32-bit time_t to 64-bit! Instead they use specific or variable size integer types.
- account42 2y ago
  Broad statements like this are universally untrue.
cryptonector 2y ago
Those databases might not even use `time_t`. It's their problem anyways, not the OS's.
pezezin 2y ago
Does any database actually use time_t? PostgreSQL uses its own datatype, the number of microseconds since 4713 BC. I am sure that other databases do the same. https://www.postgresql.org/docs/current/datatype-datetime.html https://www.postgresql.org/docs/current/datatype-datetime.ht...
- account42 2y ago
  How the timestamps are stored on disk is irrelevant if the code data from those databases ends up using time_t (e.g. because it needs to compare stored timestamps with the current time).

You would then lose the ability to represent times before Jan. 1st, 1970. Which is not just a theoretical concern; those times appear e.g. in databases with people's date of birth.

nobluster 2y ago

And a signed 32 bit time_t with an epoch of 1970 cannot represent dates before 1902. Using time_t to store legacy dates is not advisable - even if you ignore all the issues with time zones and changing local laws pertaining to offsets from UTC and daylight saving time.

pwg 2y ago
While true, that limitation has always existed, so everyone has already implemented whatever was necessary to represent dates earlier than that. Changing 32-bit time_t to unsigned suddenly makes all dates from 1902 to Jan 1 1970 which were stored using time_t (even if it was non-advisable, it still will have occurred) appear to teleport into the future beyond 2038.
- cryptonector 2y ago
  That's alright, see, because I have no filesystems, no tarballs, no backups, no files on any kind of media with timestamps before 1970, and indeed, no one can except by manually setting those timestamps -- and why bother doing that?! So any pre-1970 32-bit signed timestamps will be in... not spreadsheets, in what? In databases? No, not either. So in some sort of documents, so software consuming those will need fixing, but we're not going to see much teleporting of 1902-1970 timestamps to 2038-2106. I'm not concerned.
  - jasomill 2y ago
    Many important software projects predate UNIX. Perhaps you want to create a Git repository for one of them, with historically accurate commit timestamps?
    - loeg 2y ago
      Git represents timestamps in ASCII strings, like "12345." Not time_t. (I am not sure if it even allows negative integers in this format.)
      - jasomill 2y ago
        I was just using Git as an example of an application where pre-1970 timestamps could be useful. But as it turns out, $ git commit -m foo --date='1969-12-31 00:00:00' [main 25b6e63] foo Date: Sun Dec 30 23:00:00 2012 -0500 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 bar
    - cryptonector 2y ago
      Well, Git doesn't seem to set file timestamps when cloning. And as the sibling comment says, Git doesn't use 32-bit signed integers to store timestamps. So this is not a problem. If, however, Git were to some day get an option to set file mtimes and atimes at clone time to the last-modified time of the files based on commit history, then you could always just use a 64-bit system where `time_t` is 64-bit.
      - account42 2y ago
        > Well, Git doesn't seem to set file timestamps when cloning. This is intentional btw because otherwise with many build system things would not get rebuilt correctly when checking out an older snapshot.
    - cesarb 2y ago
      More importantly than a git repository, you might have archives (a .tar or equivalent) of these software projects, and might want to unpack them while preserving the timestamps contained within these archives.
      - cryptonector 2y ago
        Unix did not exist before 1970. Neither did tar. There are no tar files with files with timestamps before 1970 _unless_ you've used `touch -t 195001010000` or `utime(2)` or `futimes(3)` to set the files' time to before 1970. That seems pretty unlikely.

bloak 2y ago

Serious question: do people use time_t for representing a date of birth? To me that wouldn't seem right: a date of birth isn't a timestamp and you typically receive it without a corresponding place or time zone so there's no reasonable way to convert it into a timestamp. (The other problem is that a signed 32-bit time_t only goes back to 1901. You might not have to deal with a date of birth before 1901 today, unless you're doing genealogy, of course, but until fairly recently it's something you'd probably want to be able to handle.)

nomel 2y ago
My birth certificate has location, day, year, hour, and minute of birth. Birth is an event in time, perfectly represented with a (UTC) timestamp.
- Merad 2y ago
  Your birth is an event that happened at an instant in time, but very few systems concern themselves with that detail. The vast majority need to store birth _date_ and have no interest in the time or location.
  - nomel 2y ago
    > have no interest in the time Setting the bottom couple of bytes to zero achieves this, while maintaining nearly universal consistency with all other events in time that might need to be related with a packing of bits. People do it because it's what's being used at nearly every other level of the stack.
- cryptonector 2y ago
  > Birth is an event in time, perfectly represented with a (UTC) timestamp. That's not the same thing as `time_t` though. `time_t` is UTC. UTC is not `time_t`.
School-Cotton 2y ago
> Serious question: do people use time_t for representing a date of birth? I have seen people in real life use seconds since the UNIX epoch to represent DOB, yes.

loeg 2y ago

Databases do not and can not use system time_t. Consider how their on-disk state would be impacted by a change from 32-bit time_t to 64-bit! Instead they use specific or variable size integer types.

account42 2y ago
Broad statements like this are universally untrue.

cryptonector 2y ago

Those databases might not even use `time_t`. It's their problem anyways, not the OS's.

pezezin 2y ago

Does any database actually use time_t? PostgreSQL uses its own datatype, the number of microseconds since 4713 BC. I am sure that other databases do the same. https://www.postgresql.org/docs/current/datatype-datetime.html https://www.postgresql.org/docs/current/datatype-datetime.ht...

account42 2y ago
How the timestamps are stored on disk is irrelevant if the code data from those databases ends up using time_t (e.g. because it needs to compare stored timestamps with the current time).