Printable View
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
Quote:
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.
Of course... It's UNIX...Quote:
This smells like a hack.
In 300 years...
Quote:
Originally Posted by Salem
Hang on.
By these calculations, the inflation should be a lot more! "Fixed" quote below.
Quote:
Originally Posted by Salem
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 . . . .
Yeah, I just couldn't be bothered to draw a proper chart to see how the memory size would expand.Quote:
Originally Posted by dwks
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, 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.Quote:
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.
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, 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.Quote:
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.
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.
Memory doesn't quite double every two years; if it did, we'd have almost 80 GB of memory by now.
Anyway, looks like about 300 years from now, with Moore's Law still holding, we'd have about 10**45 GB of memory . . . .Code:$ python
Python 2.4.3 (#1, Jul 27 2009, 06:41:38)
[GCC 4.1.2 20080704 (Red Hat 4.1.2-44)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> x = 64
>>> for n in range(0, 20):
... x *= 2
...
>>> print x
67108864
>>>
Code:>>> x = 2
>>> for n in range(0, 300/2):
... x *= 2
...
>>> print x
2854495385411919762116571938898990272765493248
>>> import math
>>> math.log(x) / math.log(10)
45.455529345261155
>>>
...Wait, what kind of weird math did you use there?
log10(x) / log10(10)?
Sure, but it can be very convenient to have an embedded error value.Quote:
Originally Posted by Elysia
Can you imagine the complications that would arise if a pointer value of NULL didn't mean "error" but in fact was a valid value? You'd have to have a lot of "bool is_this_pointer_valid" all over the place.
I suppose so. Assuming overflow/underflow works as you'd expect. (Does the standard guarantee that, out of curiosity?)Quote:
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.
That's just the logarithmic base change identity (or whatever they call it). logZ(x) / logZ(N) is the same as logN(x), for any base Z.Quote:
Originally Posted by Elysia
Python's log() is actually base e, but like I said, it works for any log base.
So, for example, the log of 1024 in base 2 is
[edit] Here you go: http://en.wikipedia.org/wiki/Logarit...nging_the_base [/edit]Code:>>> math.log(1024) / math.log(2)
10.0
>>>
Perhaps not, but for functions that returns time, -1 is a waste of bits.Quote:
Originally Posted by dwks
Haha, a language expert would have to answer that one.Quote:
I suppose so. Assuming overflow/underflow works as you'd expect. (Does the standard guarantee that, out of curiosity?)
Ahh, of course. I don't know that formula off-hand.Quote:
Originally Posted by dwks
Why the hell would it work with e as base? That's ln, not log.Quote:
Python's log() is actually base e, but like I said, it works for any log base.
So basically we'll have about 10^45 GB memory in 300 years.
Umm . . . yeah, that's what I said. 10^54 B of memory, I suppose.Quote:
So basically we'll have about 10^45 GB memory in 300 years.
Of course, there's undoubtedly a nice formula which would calculate that without running a brute-force loop. What can I say; I have Python, I use it. [edit] I guess this comes close:
'Course, one should use 2GB there instead of 64K. [/edit]Code:>>> import math
>>> def logn(n, x):
... return math.log(x) / math.log(n)
...
>>> 2**(logn(2, 65536) + 300/2.0)
9.3536104789177787e+49
>>> logn(10, 2**(logn(2, 65536) + 300/2.0))
49.970979280220874
>>>
I know. It's very confusing. But computer scientists seem to always use log 2() or log e(), both of which they call "log". :) The standard C function log(), for example, also uses base e.Quote:
Why the hell would it work with e as base? That's ln, not log.
I think in this case, "that" actually equals "two's complement", and no the standard does not guarantee that. EDIT: No wait, you're using a cast, not a re-interpretation of bits. I still think it's implementation-specific, but I don't have the standard with me right here.Quote:
Originally Posted by dwks