time_t

Hi,

I cant think of a single reason why is in Unix based systems variable containing time stamp (time_t) type SIGNED.
Why wasnt this variable declared unsigned so that it could last twice as long as now. Why would time need to have a negative value at all?

-1 is returned when there is no time available.

I was always under the impression that the designers chose a signed type so that one could represent differences in time if one wanted to. I mean, you could conceivably want to figure out the difference between two times (end - start or whatever), and what if the result was negative . . . ?

But that was just uninformed guessing.

(And of course, one should really use difftime() to get the difference between time_t's instead of subtracting directly.)

Fwiw

there was originally some controversy over whether the unix time_t should be signed or unsigned. If unsigned, its range in the future would be doubled, postponing the 32-bit overflow (by 68 years). However, it would then be incapable of representing times prior to 1970. Dennis ritchie, when asked about this issue, said that he hadn't thought very deeply about it, but was of the opinion that the ability to represent all times within his lifetime would be nice. (ritchie's birth, in 1941, is around unix time −893,400,000.) the consensus is for time_t to be signed, and this is the usual practice.

thx for replies, very interesting... I like the most that the guy who declared it actually wanted it to be able to cover his whole lifetime, clever dude :-)

Meh, this whole thing is backwards. They could just start the counting earlier and use an unsigned type. This smells like a hack.
time_t seems like a poor way of dealing with time and date anyway, due to its limited range.

Around 1970, when memory was priced at 1 cent per byte (think about that as you plug a 1GB DIMM module into your PC next time).

Also that 1 cent would be nearer $1 in today's money, after 40 years of inflation.

Also that in 1970, the machine that C was first developed on had a stunning 64K of memory.

Spending lots of money on a problem that was 30 years away wasn't a priority.

Aye, hack it is. The good old days when future compatibility simply wasn't considered.

This smells like a hack.

Of course... It's UNIX...

In 300 years...

Originally Posted by Salem

Around 2020, when memory was priced at 1 cent per gigabyte (think about that as you plug a 1PB DIMM module into your PC next time).

Also that 1 cent would be nearer $1 in today's money, after 300 years of inflation.

Also that in 2020, the machine that C was used on had a stunning 2GB of memory.

Spending lots of money on a problem that was 300 years away wasn't a priority.

Hang on.
By these calculations, the inflation should be a lot more! "Fixed" quote below.

Originally Posted by Salem

Around 2020, when memory was priced at 1 cent per gigabyte (think about that as you plug a 1PB DIMM module into your PC next time).

Also that 1 cent would be nearer $7.5 in today's money, after 300 years of inflation.

Also that in 2020, the machine that C was used on had a stunning 2GB of memory.

Spending lots of money on a problem that was 300 years away wasn't a priority.

Wouldn't it be at least a QIMM by then? (And wow, who fixed the problem of inflation?) [I see Elysia caught that one too.]

Well, if you're going to use a single fixed-size integer to represent time, you'll always be running into this problem at some point. It would probably be best to use an insanely wide integer to represent it, but of course that uses lots of resources (and dealing with 16-byte numbers or whatever is a pain anyway). time_t was probably the best thing the designers of UNIX could have done at the time.

Consider this: by having a signed time_t, we have to deal with the problem sooner, and maybe we'll come up with a better solution this time around. Imagine if it were unsigned, and the UNIX epoch ended about 2106. We'd get around to dealing with it by the time hovercars depended on time_t software . . . .

Originally Posted by dwks

Wouldn't it be at least a QIMM by then? (And wow, who fixed the problem of inflation?) [I see Elysia caught that one too.]

Yeah, I just couldn't be bothered to draw a proper chart to see how the memory size would expand.
I can't think of a really proper formula either.
We know that:
- In 40 years, our memory size expanded from 64 KB to 2 GB (that's 2 GB - 64 KB).
- Memory sizes are increasing exponentially.
- Memory capacity is doubled every 2 years or so.

So if anyone wants to come up with a proper function to represent a graph that we could use to determine the actual (theoretical) memory size at that point, feel free to do it!

Well, if you're going to use a single fixed-size integer to represent time, you'll always be running into this problem at some point. It would probably be best to use an insanely wide integer to represent it, but of course that uses lots of resources (and dealing with 16-byte numbers or whatever is a pain anyway). time_t was probably the best thing the designers of UNIX could have done at the time.

Well, I think they could have started counting earlier and made it unsigned. The whole negative time is like a hack: they added it to represent earlier dates after the date functions had been finalized.
But I'm more of a fan of the tm struct anyway. It's a very nice and structured way of dealing with time and date.

Well, I think they could have started counting earlier and made it unsigned. The whole negative time is like a hack: they added it to represent earlier dates after the date functions had been finalized.

Well, sure, using signed numbers solely to represent dates before 1970 is not a good idea. But signed time_ts have other benefits, as described above. It allows -1 to be an error value (though -1u could be in case of unsigned numbers), and differences in time (even negative differences) to be represented more easily.

I don't find that to be much of benefit.
First off, all functions should really take an argument and return bool, or some other type to indicate failure instead of making it signed and having all negative numbers mean failure (waste of bits!).
Secondly, signed mathematics on unsigned types should work:

typedef unsigned int uint;
uint SomeNum1, SomeNum2;
int Diff = (int)(SomeNum2 - SomeNum1);

I've left out the initialization on purpose.