zdump

Dan Cotruta dancotruta at linnoc.net
Tue Aug 12 12:22:21 UTC 2008


Right, sorry about the confusion yesterday - any ideas on the Pacific/Guam
error? Also, I realise that it should be Africa/Madagascar (or Mauritius).
It was near the end of the day for me and I think I was running on fumes.

I'm currently in the process of writing a python parser for the data files -
but I've just noticed that some of the lines are NOT tab delimited. Any
ideas on this?

Example:

Rule    EUAsia    1981    max    -    Mar    lastSun     1:00u    1:00    S
Rule    EUAsia    1979    1995    -    Sep    lastSun     1:00u    0    -
Rule    EUAsia    1996    max    -    Oct    lastSun     1:00u    0    -
----------------------From this point on there's no tab between the word
Rule and the zone name-----------------
Rule E-EurAsia    1981    max    -    Mar    lastSun     0:00    1:00    S
Rule E-EurAsia    1979    1995    -    Sep    lastSun     0:00    0    -
Rule E-EurAsia    1996    max    -    Oct    lastSun     0:00    0    -
Rule RussiaAsia    1981    1984    -    Apr    1     0:00    1:00    S
Rule RussiaAsia    1981    1983    -    Oct    1     0:00    0    -
Rule RussiaAsia    1984    1991    -    Sep    lastSun     2:00s    0    -
Rule RussiaAsia    1985    1991    -    Mar    lastSun     2:00s    1:00
S
Rule RussiaAsia    1992    only    -    Mar    lastSat    23:00    1:00    S
Rule RussiaAsia    1992    only    -    Sep    lastSat    23:00    0    -
Rule RussiaAsia    1993    max    -    Mar    lastSun     2:00s    1:00    S
Rule RussiaAsia    1993    1995    -    Sep    lastSun     2:00s    0    -
Rule RussiaAsia    1996    max    -    Oct    lastSun     2:00s    0    -


This occurs in a number of places and it makes writing a search algorithm a
lot harder - I wonder if anyone has any input.


Dan

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

> 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.
>



-- 
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/20080812/db02e967/attachment-0001.html 


More information about the tz mailing list