> GP's point still stands. MS-DOS fits that range without 64-bits

32-bit Unix timestamps would have a broader range than MS-DOS timestamps if they made the same sacrifice in resolution and only had 2-second precision rather than single-second precision [1]. And if Unix timestamps additionally used 32-bit unsigned numbers to sacrifice the ability to represent timestamps before the beginning of the epoch, then the year 2038 problem would instead be more of a year 2242 problem.

[1] https://docs.microsoft.com/en-us/windows/win32/api/winbase/n...

I work with a fully POSIX-compliant OS that uses 32-bit unsigned int time_t. Unfortunately, most software these days (including the runtimes of major production languages) assume incorrectly that time_t is an unsigned int because that's what it is in the GNU C library used on GNU/Linux, and they end up using it as a general arithmetic type. The end result is undefined behaviour. But hey, it just happens to work on Linux so it must be correct. Grrr.

Linux and BSDs. They are still used quite often, and for the most cases are compatible with Linux.

Why would it result in undefined behavior? Overflow behavior is only defined on unsigned types.

Also, why should people care about your special snowflake OS? The C standard doesn't even specify that time_t has to be an integral type, but anyone who expects code to cope with a floating point time_t is deluded. Why is your case any different?

My special snowflake OS is embedded in millions of devices all over the world in safety-critical applications. It's not broken, it's the third-party software that incorrectly assumes time_t is a general integer arithmetic type that's broken.

The ISO C11 standard only says that time_t is a real type that holds values >= 0. The minute you start performing arithmetic on that type and checking if the result is less than zero you're entering undefined behaviour territory. For example, does the following program halt?

  int main() {
    for (unsigned i = 1; i >= 0); --i)
      ;
  }

The answer is "maybe". The C standard defines an infinite loop like this as undefined behaviour ISO 9899:2011 [6.8.5/6].

> a separately correct design decision would have been to use 64-bits of time from the starta separately correct design decision would have been to use 64-bits of time from the start

On a 16-bit machine when memory cost close to a dollar a byte?

yes

what percent of memory do dates usually use? Even in a spreadheet, it wouldn't double needed memory at worst it would probably be signficantly less then 10% extra memory

A PDP-11/20 could address (without extensions) 32 16-byte kilowords, or 64 kilobytes, of RAM. Most machines shipped with twelve kilowords, or 24 kilobytes, of RAM.

Tell me again how free the creators of Unix should've been with it.