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 diff
[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 n
[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?
>
>
[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 proble
> > 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 s
> 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 :-)
-
> 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
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] .
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 ret
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
[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
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 SIGN
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 PROTECTE
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
> 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 ov
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-Un
16 matches
Mail list logo
