zdump

[Dan Cotruta]

Oh - and forgive the confusion above between Mauritius and Madagascar.

On Mon, Aug 11, 2008 at 5:05 PM, Dan Cotruta <dancotruta at linnoc.net> wrote:

> Sorry, I should have also added this failure case:
>
> [dcotruta at linnoc ~]$ /usr/sbin/zdump -v -c 2009 Pacific/Guam
> Pacific/Guam  -9223372036854775808 = NULL
> Pacific/Guam  -9223372036854689408 = NULL
> Pacific/Guam  Tue Dec 31 14:20:59 1844 UTC = Mon Dec 30 23:59:59 1844 ChST
> isdst=0 gmtoff=-51660
> Pacific/Guam  Tue Dec 31 14:21:00 1844 UTC = Wed Jan  1 00:00:00 1845 ChST
> isdst=0 gmtoff=34740
> Pacific/Guam  Mon Dec 31 14:20:59 1900 UTC = Mon Dec 31 23:59:59 1900 ChST
> isdst=0 gmtoff=34740
> Pacific/Guam  Mon Dec 31 14:21:00 1900 UTC = Tue Jan  1 00:21:00 1901 ChST
> isdst=0 gmtoff=36000
> Pacific/Guam  9223372036854689407 = NULL
> Pacific/Guam  9223372036854775807 = NULL
>
> Any ideas on how the t_time / int problem relates to this?
>
>
>
> On Mon, Aug 11, 2008 at 4:57 PM, Dan Cotruta <dancotruta at linnoc.net>wrote:
>
>> Dear Olson,
>>
>> Many thanks for your quick reply. I did go through the archives a little
>> more carefully after sending my question. As I'm not a C programmer - can
>> you just confirm my understanding of the problem?
>>
>> time_t is part of a standard C library; on 64 bit systems it is defined as
>> being 64 bits long, giving a very large range for the years that can be
>> displayed.
>> int is the standard builtin integer type, which for reasons that evade me
>> is still defined as 32 bits long.
>>
>> the tzcode does some fancy calculations to work out historical/future
>> times of some kind - and obviously trying to fit a 64 bit value into a 32
>> bit space doesn't work.
>>
>> I hope that's right so far...
>>
>> So then:
>>
>> Why does Madagascar fail?
>> [dcotruta at linnoc ~]$ /usr/sbin/zdump -v -c 2008 Mauritius
>> Mauritius  -9223372036854775808 = NULL
>> Mauritius  -9223372036854689408 = NULL
>> Mauritius  9223372036854689407 = NULL
>> Mauritius  9223372036854775807 = NULL
>>
>> Here, the limit should be 2008 - therefore the 32 bit limit should not be
>> a problem. Am I missing something?
>>
>> I don't know anything about C programming - is this something that's
>> likely to be fixed at some point soon? I've started work on a Python version
>> of zdump to get around this limitation - is this something that might be
>> useful to the community?
>>
>> If so, I'd appreciate some help decrypting the logic of the tzdata files.
>>
>> Thanks again for your swift reply,
>>
>> Dan
>>
>>
>>
>> On Mon, Aug 11, 2008 at 2:07 PM, Olson, Arthur David (NIH/NCI) [E] <
>> olsona at dc37a.nci.nih.gov> wrote:
>>
>>> The numerical values are "number of seconds since midnight, January 1,
>>> 1970; they can be the immense values below on systems where time_t values
>>> are 64-bit entities.
>>> On such systems, extremely large and extremely small time stamps are
>>> associated with years that can't be represented in 32-bit integers, so we
>>> can't correctly convert them to "struct tm"s that represent them--that's why
>>> the NULLs pop out for these very small and very large values.
>>>
>>> From: Dan Cotruta [mailto:dancotruta at linnoc.net]
>>> Sent: Monday, August 11, 2008 8:30
>>> To: tz at lecserver.nci.nih.gov
>>> Subject: zdump
>>>
>>> Someone, please enlighten me - what do the numerical numbers in the
>>> output of zdump stand for?
>>>
>>> What I mean is, for this output:
>>>
>>> [dcotruta at linnoc ~]$ /usr/sbin/zdump -v -c 2008,2009 America/Los_Angeles
>>> America/Los_Angeles  -9223372036854775808 = NULL <------ What does this
>>> line signify?
>>> America/Los_Angeles  -9223372036854689408 = NULL <------ What does this
>>> line signify?
>>> America/Los_Angeles  Sun Mar  9 09:59:59 2008 UTC = Sun Mar  9 01:59:59
>>> 2008 PST isdst=0 gmtoff=-28800
>>> America/Los_Angeles  Sun Mar  9 10:00:00 2008 UTC = Sun Mar  9 03:00:00
>>> 2008 PDT isdst=1 gmtoff=-25200
>>> America/Los_Angeles  Sun Nov  2 08:59:59 2008 UTC = Sun Nov  2 01:59:59
>>> 2008 PDT isdst=1 gmtoff=-25200
>>> America/Los_Angeles  Sun Nov  2 09:00:00 2008 UTC = Sun Nov  2 01:00:00
>>> 2008 PST isdst=0 gmtoff=-28800
>>> America/Los_Angeles  9223372036854689407 = NULL <------ What does this
>>> line signify?
>>> America/Los_Angeles  9223372036854775807 = NULL <------ What does this
>>> line signify?
>>>
>>> The number is far too large to be a standard timestamp, even in
>>> milliseconds... so what is it?
>>>
>>> Many thanks,
>>> --
>>> Dan Cotruta
>>> Operations Manager, London Innovation Centre.
>>>
>>> Tel: 0203 006 7278
>>> Mob: 0779 163 4020
>>>
>>> London Innovation Centre, Lombard House, 2 Purley Way, Croydon CR0 3JP
>>> (T) 0845 262 8545 (F) 020 8481 0460 (e) info at linnoc.net (w)
>>> www.linnoc.net
>>> London Innovation Centre is a trading name of Kingston Innovation Centre
>>> (Properties) Limited.
>>> Registered in England under no. 4557707.
>>>
>>
>>
>>
>> --
>> Dan Cotruta
>> Operations Manager, London Innovation Centre.
>>
>> Tel: 0203 006 7278
>> Mob: 0779 163 4020
>>
>> London Innovation Centre, Lombard House, 2 Purley Way, Croydon CR0 3JP
>> (T) 0845 262 8545 (F) 020 8481 0460 (e) info at linnoc.net (w)
>> www.linnoc.net
>> London Innovation Centre is a trading name of Kingston Innovation Centre
>> (Properties) Limited.
>> Registered in England under no. 4557707.
>>
>
>
>
> --
> Dan Cotruta
> Operations Manager, London Innovation Centre.
>
> Tel: 0203 006 7278
> Mob: 0779 163 4020
>
> London Innovation Centre, Lombard House, 2 Purley Way, Croydon CR0 3JP
> (T) 0845 262 8545 (F) 020 8481 0460 (e) info at linnoc.net (w) www.linnoc.net
> London Innovation Centre is a trading name of Kingston Innovation Centre
> (Properties) Limited.
> Registered in England under no. 4557707.
>



-- 
Dan Cotruta
Operations Manager, London Innovation Centre.

Tel: 0203 006 7278
Mob: 0779 163 4020

London Innovation Centre, Lombard House, 2 Purley Way, Croydon CR0 3JP
(T) 0845 262 8545 (F) 020 8481 0460 (e) info at linnoc.net (w) www.linnoc.net
London Innovation Centre is a trading name of Kingston Innovation Centre
(Properties) Limited.
Registered in England under no. 4557707.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mm.icann.org/pipermail/tz/attachments/20080811/d29ea310/attachment-0001.html