Bug#584662: libdate-manip-perl: Behaviour of ambiguous timezones has changed

[Chris Butler]

tags 584662 - fixed-upstream
thanks

On Sat Jun 05 07:27:52 2010, SBECK wrote:
> What you are reporting is not a bug in v6... it's actually a bug in v5
> that is now fixed.
> 
> Date::Manip v5 treated timezone abbreviations (e.g. EST) as timezones,
> so it treated EST the same way as the timezone America/New_York.
> Clearly, this is NOT the correct behavior, and v6 finally corrects that.
> V6 uses the abbreviations to determine a timezone in a way that produces
> a correct date. In other words, in the America/New_York timezone, the
> abbreviation on Jun 5 is EDT, so the date 'Jun 5 EST' is NOT in the
> America/New_York timezone. It is either in some other timezone (if there
> is a timezone that uses the EST abbreviation on Jun 5) or invalid.

Sorry, it seems I neglected to include the date in the original report. 
Actually, the date string that we're trying to parse is "March 23, 2003 
12:00 EST", which seems to be during winter time (EST) according to 
'date':

$ TZ='America/New_York' date --date '2003-03-23 12:00'
Sun Mar 23 12:00:00 EST 2003

> Finally, with respect to your suggestion that Date::Manip have a 
> way to prioritize ambiguous timezones, it does. These are
> documented in the Date::Manip::TZ manual. Look at the
> define_abbrev, define_alias, and define_offset methods.

In which case, I believe that "EST" during winter time should pick 
America over Australia. As per the discussion on the Debian bug report, 
we believe that "EST" is more commonly used to describe the American 
timezone than the Australian, so where it is ambiguous, it should prefer 
the American timezone. This would give Date::Manip the best chance of 
correctly parsing an ambiguous date.

-- 
Chris Butler <chrisb at debian.org>
  GnuPG Key ID: 4096R/49E3ACD3