Re: Debian and the millenium bug
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] .
Re: Debian and the millenium bug
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: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian and the millenium bug
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 :-) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian and the millenium bug
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 :-) I got 292,271,023,017 years ~= ( 2^62 / (60sec/min) / (60min/hr) / (24hr/day) / (365.25day/yr) - (28 year since 1970) It only has 5 digits of accuracy at best, but that's what I put on the web page (news.html). :) - Jay -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian and the millenium bug
[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. The Gregorian year amounts to 365.2425 days on average, whereas the astronomical one is 365.2422 days. That's a difference of 0.0003 days per year, or approximately one day every 3000 years. (Incidentally, did you know that this works out so weekdays are exactly the same every 400 years?) 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 difference is again in that ballpark - around AD 31000-32000, that is. And even that will only happen if enough people will still be interested in the relation of this calendar to the Christian faith at that time - which I personally doubt, frankly. MfG Kai -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian and the millenium bug
[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, POSIX stipulates that time_t has to be a standard arithmetic type C89 (ANSI (1989) / ISO (1990, same text)) assert that. Many, many programs would break if you change it. whereas long long is a non-standard extension. (Although I also seem to recall some talk of ANSI standardizing long long, so that might not be true anymore.) It's going to be in C9X, which has just published a draft for comment. Search comp.std.c in DejaNews for the last one or two weeks for the announcement. There's also an unofficial version available on the web somewhere, announced one or two weeks earlier. Don't expect the standard to be ratified before 1999-31-12, though ;-) In the meantime, Unix98 is also available on the web somewhere (can't remember that URL). MfG Kai -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian and the millenium bug
[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 be a leap year. -- Raul -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian and the millenium bug
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 difference is again in that ballpark - around AD 31000-32000, that is. Continuing off-topic, I remember that when I was young (very young) I read a nice proposal for a reform of the calendar, made by Isaac Asimov. I cannot find it anymore and, for some strange but human reason, I'm no more in the possibility to ask Isaac himself. Did anybody read it and can tell me where I could find it? Thanks, Fabrizio -- | [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] | Pluto Leader - Debian Developer Happy Debian 1.3.1 User - vi-holic | 6F7267F5 fingerprint 57 16 C4 ED C9 86 40 7B 1A 69 A1 66 EC FB D2 5E more than 35 months are needed to get rid of the millennium. [me] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian and the millenium bug
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: |butch| bc -l bc 1.04 Copyright (C) 1991, 1992, 1993, 1994, 1997 Free Software Foundation, Inc. This is free software with ABSOLUTELY NO WARRANTY. For details type `warranty'. 2^31 2147483648 2^31/(60*60*24*365) 68.09625976661593099949 Just moving to unsigned int will give you 68 more years, up to year 2106: 2^32 4294967296 2^32/(60*60*24*365) 136.19251953323186199898 1970+136 2106 So it's even simpler in regards of type size, but moving to an unsigned int may cause serious troubles in comparing dates (unless you use some functions which hide thedetails). |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...) Where did you get this 4000 years figure anyway? 33 bits would just double the duration from 136 years to 272 (bringing us to year 2242). Cheers, --Amos --Amos Shapira| Of course Australia was marked for 133 Shlomo Ben-Yosef st. | glory, for its people had been chosen Jerusalem 93 805 | by the finest judges in England. ISRAEL[EMAIL PROTECTED] | -- Anonymous -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian and the millenium bug
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 PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian and the millenium bug
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 (31 bits) instead of unsigned bits: ... Just moving to unsigned int will give you 68 more years, up to year 2106: but would make it impossible to represent dates from 1902 to 1969, which we can do now. So it's even simpler in regards of type size, but moving to an unsigned int may cause serious troubles in comparing dates (unless you use some functions which hide thedetails). You would break anything that used dates earlier than 1970. 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? -- Oliver Elphick[EMAIL PROTECTED] Isle of Wight http://www.lfix.co.uk/oliver PGP key from public servers; key ID 32B8FAA1 Unsolicited email advertisements are not welcome; any person sending such will be invoiced for telephone time used in downloading together with a £25 administration charge. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian and the millenium bug
[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 = 2038) is posed by the used of SIGNED int (31 bits) instead of unsigned bits: True, but please don't change that. You'd break the doc-rfc package - there are RFCs from 1969 in it :-) |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...) Where did you get this 4000 years figure anyway? 33 bits would just double the duration from 136 years to 272 (bringing us to year 2242). True. And 64 bits gives us +/- 68*4*10^9 years, or over 250*10^9 years. 10^9 = 1 milliard (where applicable) or 1 billion (elsewhere). Nothing like billions of billions there. Hmm. I think that goes farther back than the beginning of the universe, so it's probably barely enough :-) MfG Kai -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian and the millenium bug
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 is a non-standard extension. (Although I also seem to recall some talk of ANSI standardizing long long, so that might not be true anymore.) -- Michael Stone, Sysadmin, ITRI PGP: key 1024/76556F95 from mit keyserver, [EMAIL PROTECTED]finger, or email with Subject: get pgp key -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian and the millenium bug
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 retentive people noticed that you misspelled millennium. - Jay -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian and the millenium bug
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 overstating this just a bit? What about programs that store time_t's in ints? Or write them out to some kind of storage? Well, NetBSD already has a 64 bit off_t... I think the way most people expect the transition to happen is that *int* will become 64 bit, and things will just deal. Since lots of other things that assume 32 bit ints now are already starting to break (ip addresses won't fit any more, off_t's won't fit, pointers *never* fit on the alpha...) I think that system code will be fine, and legacy code will be the problem that it already is. Note also that for most applications that can't be recompiled, being really clever with the 32-bit ctime in the shared libc will cover a fair number of sins... but I hope not to catch anyone actually doing that :-) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian and the millenium bug
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 world is going through - we go through more work to produce a major release of Debian. Once time_t is a 64 bit variable, it's good for another 4000 years. Don't you think you're overstating this just a bit? What about programs that store time_t's in ints? Or write them out to some kind of storage? What about compatibility with other software (netscape or staroffice, for example) that you can't recompile? (Yes, I know they're not part of the distribution, but it's unrealistic to ignore them.) If it were as easy as you're making it out to be, it would have already been done. -- Michael Stone, Sysadmin, ITRI PGP: key 1024/76556F95 from mit keyserver, [EMAIL PROTECTED]finger, or email with Subject: get pgp key -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
