Re: DateTime::TimeZone problems on FreeBSD
On Thu, Dec 04, 2003 at 09:00:54PM +0100, Anton Berezin [EMAIL PROTECTED] wrote: For example, EST is used for Eastern Standard Time, aka America/New_York, but also for parts of Australia. Even EST in the US is ambiguous, because it's also used for America/Indianapolis, a time zone that does not observe DST, in addition to America/New_York, which does observe EST. There's been discussion about this on the list, but I'll repeat this over and over. The various 3 and 4 letter abbreviations sometimes used colloquially for time zones are often not sufficient to accurately determine what the actual time zone is, and should only be used for display purposes, as in January 4, 2003 11:00 EST. Setting your system's time zone to such a thing is asking for trouble. I really don't know. Three-letter abbreviations are POSIX.1. They might be obsolete, but they are still supported by most implementations, and used widely. Umm, a posix-style TZ looks like this: stdoffset[dst[offset][,start[/time],end[/time]]] So at minimum you would have TZ=CET-1 (std and offset). (Note that the offsets are negative east of GMT and positive west of GMT.) If you are using just TZ=CET, I suspect you *do* have an Olson tz entry for CET. Indeed, I see one in tzdata/europe: # These are for backward compatibility with older versions. # Zone NAMEGMTOFF RULES FORMAT [UNTIL] ZoneWET 0:00EU WE%sT ZoneCET 1:00C-Eur CE%sT ZoneMET 1:00C-Eur ME%sT ZoneEET 2:00EU EE%sT It would be nice to have an option to include all the backward-compatibility timezones in DateTime.
DateTime::TimeZone problems on FreeBSD
Hi, [Please Cc me in any replies, since I am not on the list] With DateTime::TimeZone 0.25.05, the following is likely to bork with Cannot determine local time zone: perl -MDateTime::TimeZone -le '$t = DateTime::TimeZone-new(name = local);' The reasons for that are: - if TZ environment variable is not set, TimeZone tries /etc/localtime, which is present on FreeBSD. Unfortunately, on FreeBSD this file is *NOT* a symlink to a timezone name, but a FreeBSD-specific binary file (see tzfile(5) for details); - even if TZ is set, it is very likely to contain something like CET, which DateTime::TimeZone knows nothing about. Only if TZ is set to something like Europe/Copenhagen, will DateTime::TimeZone work, and this is in my experience very uncommon among FreeBSD users. - the other methods DateTime::TimeZone tries are not applicable for FreeBSD. I have too little knowledge of the module inner workings to provide a patch, unfortunately. Cheers, %Anton. -- Civilization is a fractal patchwork of old and new and dangerously new. -- Vernor Vinge
Re: DateTime::TimeZone problems on FreeBSD
On Thu, 4 Dec 2003, Anton Berezin wrote: - if TZ environment variable is not set, TimeZone tries /etc/localtime, which is present on FreeBSD. Unfortunately, on FreeBSD this file is *NOT* a symlink to a timezone name, but a FreeBSD-specific binary file (see tzfile(5) for details); Slaven Rezic submitted a patch a while back that tries to figure out which file this is a copy of, specifically for annoying OS's like FreeBSD that do this ;) It's applied in CVS, and wlil be in the next release. - even if TZ is set, it is very likely to contain something like CET, That's not a time zone. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DateTime::TimeZone problems on FreeBSD
+-le 04/12/2003 10:05 -0600, Dave Rolsky écrivait : | On Thu, 4 Dec 2003, Anton Berezin wrote: | | - even if TZ is set, it is very likely to contain something like CET, | | That's not a time zone. Hum, what is it if not a time zone ? -- Mathieu Arnold
Re: DateTime::TimeZone problems on FreeBSD
On Thu, 4 Dec 2003, Mathieu Arnold wrote: +-le 04/12/2003 10:05 -0600, Dave Rolsky écrivait : | On Thu, 4 Dec 2003, Anton Berezin wrote: | | - even if TZ is set, it is very likely to contain something like CET, | | That's not a time zone. Hum, what is it if not a time zone ? It's a 3 letter abbreviation that _could_ represent one _or more_ time zones, at least sometimes. In other words, these abbreviations are not unique, nor are they indicative of exactly what rules are in effect. For example, EST is used for Eastern Standard Time, aka America/New_York, but also for parts of Australia. Even EST in the US is ambiguous, because it's also used for America/Indianapolis, a time zone that does not observe DST, in addition to America/New_York, which does observe EST. There's been discussion about this on the list, but I'll repeat this over and over. The various 3 and 4 letter abbreviations sometimes used colloquially for time zones are often not sufficient to accurately determine what the actual time zone is, and should only be used for display purposes, as in January 4, 2003 11:00 EST. Setting your system's time zone to such a thing is asking for trouble. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DateTime::TimeZone problems on FreeBSD
On Thu, 4 Dec 2003, Thomas Bergmann wrote:
I had the some problem Cannot determine local time zone on W2K.
i dont like to set an additional enviroment variable TZ to find the right
TimeZone on the server, because
perl knows the timezone. gmtime and localtime work fine. So i wrote a
small function to get the local timezone.
is there any comparable at CPAN modules?
# $timezone = local_time_zone() # in format: sign\d{2}:\d{2}
sub local_time_zone {
my $timer = time;
my ($sec,$min,$hour,$mday,$mon,$year) = localtime($timer);
my $loc_time = sprintf(%4d-%02d-%02d %02d:%02d:%02d,$year + 1900,$mon
+ 1,$mday,$hour,$min,$sec);
($sec,$min,$hour,$mday,$mon,$year) = gmtime($timer);
my $gmt_time = sprintf(%4d-%02d-%02d %02d:%02d:%02d,$year + 1900,$mon
+ 1,$mday,$hour,$min,$sec);
my $Strp = new DateTime::Format::Strptime(
pattern = '%F %T',
locale = 'en_AU',
time_zone = '+',
);
my $d = $Strp-parse_datetime($loc_time) -
$Strp-parse_datetime($gmt_time);
my $time_zone = sprintf(%s%02d:%02d,$d-is_negative ? '-' : '+' ,
$d-hours,$d-minutes);
return $time_zone;
}
Unfortunately, this isn't a time zone either. Rather, it's an offset from
UTC that's valid at a specific moment in time.
Time zones are made up of multiple observances representing the historical
changes in that particular zone. Each observance consists of:
- A base offset from UTC
- A set of 0+ rules defining DST changes during that observance
All the time zones have at least two observances, and a lot of them have
more.
Simply knowing the current UTC offset does not tell you if DST is in
effect, and more importantly, it doesn't tell you when that offset will
change because of a rule-specified DST change.
I'd love to get some code in there that works on Win32, but it needs to
get an actual time zone, not just an offset.
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
Re: DateTime::TimeZone problems on FreeBSD
On Thu, 4 Dec 2003, Anton Berezin wrote: Setting your system's time zone to such a thing is asking for trouble. I really don't know. Three-letter abbreviations are POSIX.1. They might be obsolete, but they are still supported by most implementations, and used widely. POSIX is wrong. What else can I say? POSIX also said that 2000 wasn't a leap year, IIRC. Tools not policy seem to apply here. I'm not sure what that means. This isn't a policy issue, it's a question of being correct. EST is not a valid Olson database time zone. If you want to make up some bogus ad hoc rule then you can always declare that EST = America/New_York, but if you have to deal with users who may be in multiple time zones for a single app, especially something like a web app where you have one database (probably storing UTC) and a need to output datetimes in multiple zones, then you'll have to do this correctly. As for the DateTime project, there's a DateTime::TimeZone::Alias module that lets you associate arbitrary names (abbreviations or whatever) with a real time zone name. But you'd have to define the EST = America/New_York mapping in your own code. Stuff like that will never be part of the core. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DateTime::TimeZone problems on FreeBSD
On Thu, 4 Dec 2003, Anton Berezin wrote: Maybe have a default aliases like certain annoying OS's, to borrow your expression? As a matter of fact, last time I tried, Linux did the same thing - understood them. EST actually designates Indianapolis time - America/Indianapolis and EST are hardlinked (I presume because it is EST all year round), and CET is, I believe, quite unambiguous. Well, if the OS symlinks /etc/localtime to /usr/share/zoneinfo/EST, which is in turn linked to /usr/share/zoneinfo/America/Indianapolis, that's fine, so we eventually arrive at something usable. Even funnier still, the zoneinfo package is exactly the same on Linux and FreeBSD, or at least on Debian and FreeBSD, and there is a whole bunch of three-letter abbreviations there. So why to struggle against the OS? For an abstract correctness, which might not be that correct Because the OS is wrong in this case. Since you did not buy the tools not policy principle, I appeal to the principle of least astonishment, which in this particular instance means to support what people expect and what OS's implement. You may strongly urge against using three letter abbreviations because they are not correct, but not supporting them outright would, IMHO, be a mistake. I disagree. Not supporting them outright is almost certainly abiding by the principle of least astonishment, since someone from Australia may well be quite astonished if they ask for EST and get America/Indianapolis. Now, if someone wants to add some code to DateTime::TimeZone::Local that, given an abbreviation, looks at the zoneinfo files and figures out that EST is a copy (as on my Debian box) of America/Indianapolis, and therefore turns EST into America/Indianapolis, that's fine with me. But since I cannot be sure that on other systems EST doesn't mean something else, I'm not going to hard code this into the package itself. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DateTime::TimeZone problems on FreeBSD
On Thu, Dec 04, 2003 at 02:12:27PM -0600, Dave Rolsky wrote: On Thu, 4 Dec 2003, Anton Berezin wrote: Setting your system's time zone to such a thing is asking for trouble. I really don't know. Three-letter abbreviations are POSIX.1. They might be obsolete, but they are still supported by most implementations, and used widely. POSIX is wrong. What else can I say? POSIX also said that 2000 wasn't a leap year, IIRC. Tools not policy seem to apply here. I'm not sure what that means. This isn't a policy issue, it's a question of being correct. EST is not a valid Olson database time zone. If you want to make up some bogus ad hoc rule then you can always declare that EST = America/New_York, but if you have to deal with users who may be in multiple time zones for a single app, especially something like a web app where you have one database (probably storing UTC) and a need to output datetimes in multiple zones, then you'll have to do this correctly. As for the DateTime project, there's a DateTime::TimeZone::Alias module that lets you associate arbitrary names (abbreviations or whatever) with a real time zone name. But you'd have to define the EST = America/New_York mapping in your own code. Stuff like that will never be part of the core. Maybe have a default aliases like certain annoying OS's, to borrow your expression? As a matter of fact, last time I tried, Linux did the same thing - understood them. EST actually designates Indianapolis time - America/Indianapolis and EST are hardlinked (I presume because it is EST all year round), and CET is, I believe, quite unambiguous. Even funnier still, the zoneinfo package is exactly the same on Linux and FreeBSD, or at least on Debian and FreeBSD, and there is a whole bunch of three-letter abbreviations there. So why to struggle against the OS? For an abstract correctness, which might not be that correct after all (what if I live in Andorra and ask for CET times before 1985; they are different from Andorra times) ? Since you did not buy the tools not policy principle, I appeal to the principle of least astonishment, which in this particular instance means to support what people expect and what OS's implement. You may strongly urge against using three letter abbreviations because they are not correct, but not supporting them outright would, IMHO, be a mistake. Cheers, \Anton. -- Civilization is a fractal patchwork of old and new and dangerously new. -- Vernor Vinge
