Remember Emerson: A foolish consistency is the hobgoblin of small minds.
Bruce
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Why does glibc2 not use long long (64 bits) for dates, insead of long int
(32 bits)? Surely we ought to change this now along with all the other
libc6 changes?
We have to get POSIX to bless it first. We have 40 years to do it, relax.
Bruce
--
TO UNSUBSCRIBE FROM THIS MAILING LIST:
Where did you get this 4000 years figure anyway? 33 bits would just
Oh, having become hopelessly confused by the original posting, I came
up with some additional errors (the 16x10^18 is just as wrong, too;
584,942,417,355 is more like it...) Comes of posting to debian lists
in my sleep :-)
Where did you get this 4000 years figure anyway? 33 bits would just
Oh, having become hopelessly confused by the original posting, I came
up with some additional errors (the 16x10^18 is just as wrong, too;
584,942,417,355 is more like it...) Comes of posting to debian lists
in my sleep
[EMAIL PROTECTED] wrote on 05.01.98 in [EMAIL PROTECTED]:
Well, there is a problem with the Gregorian calendar that has to be dealt
with in 2000 years or so (having to do with leap-millenia), but I figure
if it's more than 100 years it's no problem.
That depends on what you call a problem.
[EMAIL PROTECTED] (Michael Stone) wrote on 05.01.98 in [EMAIL PROTECTED]:
Quoting Oliver Elphick (olly@lfix.co.uk):
Why does glibc2 not use long long (64 bits) for dates, insead of long int
(32 bits)? Surely we ought to change this now along with all the other
libc6 changes?
IIRC,
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Well, there is a problem with the Gregorian calendar that has to be
dealt with in 2000 years or so (having to do with leap-millenia), but
I figure if it's more than 100 years it's no problem.
I believe that can be handled by making the year 4000 not
On 6 Jan, Kai Henningsen wrote:
Remember that the last calendar reform was made at an actual difference of
about 10 days (and some countries took a long time after that to implement
it, thus increasing the difference even more), so I'd expect people won't
touch that until the
In message [EMAIL PROTECTED] you write:
| a 64 bit variable, it's good for another 4000 years.
|
|Uhhh -- no. If it went from 32 bits to *33* bits, that would get us
Actually, the current limit of 68 years (1970 + 68 = 2038) is posed by
the used of SIGNED int (31 bits) instead of unsigned bits:
Well, there is a problem with the Gregorian calendar that has to be dealt
with in 2000 years or so (having to do with leap-millenia), but I figure
if it's more than 100 years it's no problem.
Bruce
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to
[EMAIL
Amos Shapira wrote:
In message [EMAIL PROTECTED] you write:
| a 64 bit variable, it's good for another 4000 years.
|
|Uhhh -- no. If it went from 32 bits to *33* bits, that would get us
Actually, the current limit of 68 years (1970 + 68 = 2038) is posed by
the used of SIGNED int
[EMAIL PROTECTED] (Amos Shapira) wrote on 05.01.98 in [EMAIL PROTECTED]:
In message [EMAIL PROTECTED] you write:
| a 64 bit variable, it's good for another 4000 years.
|
|Uhhh -- no. If it went from 32 bits to *33* bits, that would get us
Actually, the current limit of 68 years (1970 + 68
Quoting Oliver Elphick (olly@lfix.co.uk):
Why does glibc2 not use long long (64 bits) for dates, insead of long int
(32 bits)? Surely we ought to change this now along with all the other
libc6 changes?
IIRC, POSIX stipulates that time_t has to be a standard arithmetic type
whereas long long
Bruce,
You are causing me all sorts of trouble. The post used the word
'effected' when 'affected' is what you wanted. Some of the letters
I'm getting are quite detailed in their explanation of why effected
is incorrect. Want me to send them to you? ;)
The best part is that none of these anal
a 64 bit variable, it's good for another 4000 years.
Uhhh -- no. If it went from 32 bits to *33* bits, that would get us
4000 years. This gets us more like 16 billion billion years (american
billions - 16 x 10^18 is what I mean, but it's off the top of my head...)
Don't you think you're
Originally on debian-announce, but it seems development related...
Quoting [EMAIL PROTECTED] ([EMAIL PROTECTED]):
Before 2036 we must define time_t, to be a 64-bit variable instead of
a 32-bit one, and recompile all programs. This is a very simple process
compared to the anguish the non-Unix
16 matches
Mail list logo
