4 ms·

While true, that limitation has always existed, so everyone has already implemented whatever was necessary to represent dates earlier than that. Changing 32-bi

by 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.
      - account42 2y ago
        If I create a new archive format today and use it to archive the contents of my disk or whatever USB stick I find do you not thing it might end up containing files with timestamps before today?

by pwg 2y ago

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.
    - account42 2y ago
      If I create a new archive format today and use it to archive the contents of my disk or whatever USB stick I find do you not thing it might end up containing files with timestamps before today?