Olson database name ambiguity
Hi Apologies for cross posting this. I think that this is a problem in the data in the Olson database, but as it is a binary format it is difficult to verify this. I have come across this problem using the DateTime perl module (version 0.28) whose data is generated from the Olson database. The problem that I am experiencing is that the short name for timezones for 'Europe/London' up until 1996 were either 'GMT' or 'BST' (depending if daylight saving changes were in effect). From 1996 the name for the timezone is the rather less precise 'GMT/BST' regardless of whether daylight saving changes are in effect or not. I have attached a script that demonstrates this, and its output. Regards, Tom winter 1970: BST (3600) ... summer 1970: BST (3600) winter 1971: BST (3600) ... summer 1971: BST (3600) winter 1972: GMT (0) ... summer 1972: BST (3600) winter 1973: GMT (0) ... summer 1973: BST (3600) winter 1974: GMT (0) ... summer 1974: BST (3600) winter 1975: GMT (0) ... summer 1975: BST (3600) winter 1976: GMT (0) ... summer 1976: BST (3600) winter 1977: GMT (0) ... summer 1977: BST (3600) winter 1978: GMT (0) ... summer 1978: BST (3600) winter 1979: GMT (0) ... summer 1979: BST (3600) winter 1980: GMT (0) ... summer 1980: BST (3600) winter 1981: GMT (0) ... summer 1981: BST (3600) winter 1982: GMT (0) ... summer 1982: BST (3600) winter 1983: GMT (0) ... summer 1983: BST (3600) winter 1984: GMT (0) ... summer 1984: BST (3600) winter 1985: GMT (0) ... summer 1985: BST (3600) winter 1986: GMT (0) ... summer 1986: BST (3600) winter 1987: GMT (0) ... summer 1987: BST (3600) winter 1988: GMT (0) ... summer 1988: BST (3600) winter 1989: GMT (0) ... summer 1989: BST (3600) winter 1990: GMT (0) ... summer 1990: BST (3600) winter 1991: GMT (0) ... summer 1991: BST (3600) winter 1992: GMT (0) ... summer 1992: BST (3600) winter 1993: GMT (0) ... summer 1993: BST (3600) winter 1994: GMT (0) ... summer 1994: BST (3600) winter 1995: GMT (0) ... summer 1995: BST (3600) winter 1996: GMT/BST (0) ... summer 1996: GMT/BST (3600) winter 1997: GMT/BST (0) ... summer 1997: GMT/BST (3600) winter 1998: GMT/BST (0) ... summer 1998: GMT/BST (3600) winter 1999: GMT/BST (0) ... summer 1999: GMT/BST (3600) winter 2000: GMT/BST (0) ... summer 2000: GMT/BST (3600) winter 2001: GMT/BST (0) ... summer 2001: GMT/BST (3600) winter 2002: GMT/BST (0) ... summer 2002: GMT/BST (3600) winter 2003: GMT/BST (0) ... summer 2003: GMT/BST (3600) winter 2004: GMT/BST (0) ... summer 2004: GMT/BST (3600) winter 2005: GMT/BST (0) ... summer 2005: GMT/BST (3600) winter 2006: GMT/BST (0) ... summer 2006: GMT/BST (3600) winter 2007: GMT/BST (0) ... summer 2007: GMT/BST (3600) winter 2008: GMT/BST (0) ... summer 2008: GMT/BST (3600) winter 2009: GMT/BST (0) ... summer 2009: GMT/BST (3600) winter 2010: GMT/BST (0) ... summer 2010: GMT/BST (3600) winter 2011: GMT/BST (0) ... summer 2011: GMT/BST (3600) winter 2012: GMT/BST (0) ... summer 2012: GMT/BST (3600) winter 2013: GMT/BST (0) ... summer 2013: GMT/BST (3600) winter 2014: GMT/BST (0) ... summer 2014: GMT/BST (3600) winter 2015: GMT/BST (0) ... summer 2015: GMT/BST (3600) winter 2016: GMT/BST (0) ... summer 2016: GMT/BST (3600) winter 2017: GMT/BST (0) ... summer 2017: GMT/BST (3600) winter 2018: GMT/BST (0) ... summer 2018: GMT/BST (3600) winter 2019: GMT/BST (0) ... summer 2019: GMT/BST (3600) winter 2020: GMT/BST (0) ... summer 2020: GMT/BST (3600) testdt.pl Description: Perl program
Re: Olson database name ambiguity
On Mon, 7 Mar 2005, Tom Yandell wrote: Apologies for cross posting this. I think that this is a problem in the data in the Olson database, but as it is a binary format it is difficult to verify this. I have come across this problem using the DateTime perl module (version 0.28) whose data is generated from the Olson database. The text versions of the Olson database are available here: http://www.twinsun.com/tz/tz-link.htm The problem that I am experiencing is that the short name for timezones for 'Europe/London' up until 1996 were either 'GMT' or 'BST' (depending if daylight saving changes were in effect). From 1996 the name for the timezone is the rather less precise 'GMT/BST' regardless of whether daylight saving changes are in effect or not. I have attached a script that demonstrates this, and its output. Ah, I see. I think my parser interprets the data in the Olson db incorrectly. The db does just list GMT/BST, but apparently that means they alternate, not that there's just one short name for that zone at all times. Parsing the Olson DB is, ahem, not exactly fun ;) I'll fix this in the next release. -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/
Problems Installing
Hi, I am trying to install DateTime and its variety of components so I can make use of the DateTime::Timezone functionality. I am on Windows XP on my client but will need to install on Win2K (my server). Whenever I try to install either DateTime, Params::Validate, Attributes::Handlers, etc I consistently get an error on the make command at this point: +++ pm_to_blib: $(TO_INST_PM) @$(PERL) -I$(INST_ARCHLIB) -I$(INST_LIB) \ -I$(PERL_ARCHLIB) -I$(PERL_LIB) -MExtUtils::Install \ -e pm_to_blib(qw[ pmfiles.dat ],'$(INST_LIB)\auto','$(PM_FILTER)') $(PM_TO_BLIB) -- Always get an error *** missing separatort on this line of the Makefile @$(TOUCH) $@ +++ I can comment this section out but then I start getting the error: +++ [blib\lib\Attribute\.exists] Error -1 +++ I have been using DJGPP ANSI C compiler. Any ideas? Rick
RE: Olson database name ambiguity
Here is the pertinent information about the problem from Arthur Olson - thank you for providing this answer so quickly. Tom On Mon, 2005-03-07 at 15:56, Olson, Arthur David (NIH/NCI) wrote: Back at the start of 1995 the time zone source file format was updated to allow for lines containing text such as GMT/BST to be used to specify a zone that uses GMT in normal parts of the year and BST in saving parts of the year. Of course, the time zone compiler--the program that converts the source files to binary format--was also changed in 1995. The situation you're seeing comes up when someone runs post-1995 source files through a pre-1995 compiler. There are three possible courses of action: 1. Accept the situation. 2. Get some old source files to run through the old time zone compiler. 3. Get a new compiler to use on the source files. You can go to ftp://elsie.nci.nih.gov/pub to find bundles of time zone files; the classictz* files are the archived stuff from before the GMT/BST change; the tz2005* files are the up-to-date stuff. --ado __ From: Tom Yandell [mailto:[EMAIL PROTECTED] Sent: Monday, March 07, 2005 5:39 AM To: [EMAIL PROTECTED] Cc: DateTime mailing list Subject: Olson database name ambiguity Hi Apologies for cross posting this. I think that this is a problem in the data in the Olson database, but as it is a binary format it is difficult to verify this. I have come across this problem using the DateTime perl module (version 0.28) whose data is generated from the Olson database. The problem that I am experiencing is that the short name for timezones for 'Europe/London' up until 1996 were either 'GMT' or 'BST' (depending if daylight saving changes were in effect). From 1996 the name for the timezone is the rather less precise 'GMT/BST' regardless of whether daylight saving changes are in effect or not. I have attached a script that demonstrates this, and its output. Regards, Tom
RE: Problems Installing
Hi Rick, Rick Brewer wrote: I consistently get an error on the make command at this point: +++ pm_to_blib: $(TO_INST_PM) @$(PERL) -I$(INST_ARCHLIB) -I$(INST_LIB) \ -I$(PERL_ARCHLIB) -I$(PERL_LIB) -MExtUtils::Install \ -e pm_to_blib(qw[ pmfiles.dat ],'$(INST_LIB)\auto','$(PM_FILTER)') (more snippage) I have been using DJGPP ANSI C compiler. Is this the same compiler that you used to build perl? What is the output of perl -V? Ron Hill
RE: Problems Installing
Hi Rick, Rick Brewer wrote: Hi Ron, I used the ActiveState version of perl which installed w/o needing a C compiler.I installed DJGPP in order to install the dateTime modules. [snippage] perl -V shows: +++ Compiler: cc='cl.exe', ccflags ='-nologo -O1 -MD -DNDEBUG -DWIN32 -D_CONSOLE -DNO_STRICT - ^^^ This is the problem, Activestate uses microsoft's c compiler to compile perl (5.6.1) you need to this complier when installing modules that require a C compiler. you need to use the ppm utility that ships with Activestate in order to install the these modules. You can search the datetime archive to locate a depository for you version of perl. I hope this helps. Ron Hill
Is anyone using dateTime::Timezone in a Production Env ironment?
Just looking for input here, is anyone using DateTime::TimeZone in a production environment right now? We have a need to convert to-and-from a variety of time zones from Perl in a Windows environment and need to account for Daylight Savings Time. DateTime::TimeZone looks like the best option available right now. I have been making good use of Date::Manip but with the expansion of our program into timezones beyond Central European Time and the timezones here in North America, I need to find something more robust. thanks for the input, Rick
Re: Is anyone using dateTime::Timezone in a Production Env ironment?
On Mon, 7 Mar 2005, Rick Brewer wrote: Just looking for input here, is anyone using DateTime::TimeZone in a production environment right now? We have a need to convert to-and-from a variety of time zones from Perl in a Windows environment and need to account for Daylight Savings Time. DateTime::TimeZone looks like the best option available right now. I have been making good use of Date::Manip but with the expansion of our program into timezones beyond Central European Time and the timezones here in North America, I need to find something more robust. I've been using it in various apps for a bunch of clients for a while. It's been around for over a year, and judging by list traffic bug reports, I think a lot of people are using it, and I'd guess that it's in production in many places by now. -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/
