Bug#402776: still exists in 2.3.6.ds1-10

2007-01-18 Thread dann frazier
reopen 402776
found 402776 2.3.6.ds1-10
thanks

Reopening, I can still reproduce this on ia64.

[EMAIL PROTECTED]:~$ dpkg -l libc6.1
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name   VersionDescription
+++-==-==-
ii  libc6.12.3.6.ds1-10   GNU C Library: Shared libraries

[EMAIL PROTECTED]:~$ zdump -v America/New_York | head -4
America/New_York  -9223372036854775808 = NULL
America/New_York  -9223372036854689408 = NULL
America/New_York  Sun Mar 31 06:59:59 1918 UTC = Sun Mar 31 01:59:59 1918 EST 
isdst=0 gmtoff=-18000
America/New_York  Sun Mar 31 07:00:00 1918 UTC = Sun Mar 31 03:00:00 1918 EDT 
isdst=1 gmtoff=-14400
[EMAIL PROTECTED]:~$ zdump -v America/New_York | tail -4
America/New_York  Sun Nov  1 05:59:59 2037 UTC = Sun Nov  1 01:59:59 2037 EDT 
isdst=1 gmtoff=-14400
America/New_York  Sun Nov  1 06:00:00 2037 UTC = Sun Nov  1 01:00:00 2037 EST 
isdst=0 gmtoff=-18000
America/New_York  9223372036854689407 = NULL
America/New_York  9223372036854775807 = NULL

-- 
dann frazier | HP Open Source and Linux Organization


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#402776: still exists in 2.3.6.ds1-10

2007-01-18 Thread Aurelien Jarno
dann frazier a écrit :
 reopen 402776
 found 402776 2.3.6.ds1-10
 thanks
 
 Reopening, I can still reproduce this on ia64.
 
 [EMAIL PROTECTED]:~$ dpkg -l libc6.1
 Desired=Unknown/Install/Remove/Purge/Hold
 | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
 |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: 
 uppercase=bad)
 ||/ Name   VersionDescription
 +++-==-==-
 ii  libc6.12.3.6.ds1-10   GNU C Library: Shared libraries
 
 [EMAIL PROTECTED]:~$ zdump -v America/New_York | head -4
 America/New_York  -9223372036854775808 = NULL
 America/New_York  -9223372036854689408 = NULL
 America/New_York  Sun Mar 31 06:59:59 1918 UTC = Sun Mar 31 01:59:59 1918 EST 
 isdst=0 gmtoff=-18000
 America/New_York  Sun Mar 31 07:00:00 1918 UTC = Sun Mar 31 03:00:00 1918 EDT 
 isdst=1 gmtoff=-14400
 [EMAIL PROTECTED]:~$ zdump -v America/New_York | tail -4
 America/New_York  Sun Nov  1 05:59:59 2037 UTC = Sun Nov  1 01:59:59 2037 EDT 
 isdst=1 gmtoff=-14400
 America/New_York  Sun Nov  1 06:00:00 2037 UTC = Sun Nov  1 01:00:00 2037 EST 
 isdst=0 gmtoff=-18000
 America/New_York  9223372036854689407 = NULL
 America/New_York  9223372036854775807 = NULL
 

Looking more closely to the manpage it seems there is actually no bug,
the program behaves as expected:

For each zonename on the command line, print the time at the lowest
possible time value, the time one day after the lowest possible time
value, the times both one second before...

So that's normal that the output is different on architectures where
time_t has a 64-bit type.

-9223372036854775808 and 9223372036854775807 are not really
representable in our current gregorian calendar, so those date are
displayed as NULL.

-- 
  .''`.  Aurelien Jarno | GPG: 1024D/F1BCDB73
 : :' :  Debian developer   | Electrical Engineer
 `. `'   [EMAIL PROTECTED] | [EMAIL PROTECTED]
   `-people.debian.org/~aurel32 | www.aurel32.net


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#402776: still exists in 2.3.6.ds1-10

2007-01-18 Thread dann frazier
On Thu, Jan 18, 2007 at 07:38:45PM +0100, Aurelien Jarno wrote:
 Looking more closely to the manpage it seems there is actually no bug,
 the program behaves as expected:
 
 For each zonename on the command line, print the time at the lowest
 possible time value, the time one day after the lowest possible time
 value, the times both one second before...
 
 So that's normal that the output is different on architectures where
 time_t has a 64-bit type.
 
 -9223372036854775808 and 9223372036854775807 are not really
 representable in our current gregorian calendar, so those date are
 displayed as NULL.

makes sense.

-- 
dann frazier



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]