Bug #61582 for DateTime-Format-Mail: CEST missing in %timezones

I don't actually use this module. Would you be interested in taking over its maintenance?

On Thu Sep 23 03:49:19 2010, dreimer wrote: Show quoted text
RFC 2822 accepted values for time zone are listed below: zone = (( "+" / "-" ) 4DIGIT) / obs-zone obs-zone = "UT" / "GMT" / ; Universal Time ; North American UT ; offsets "EST" / "EDT" / ; Eastern: - 5/ - 4 "CST" / "CDT" / ; Central: - 6/ - 5 "MST" / "MDT" / ; Mountain: - 7/ - 6 "PST" / "PDT" / ; Pacific: - 8/ - 7 %d65-73 / ; Military zones - "A" %d75-90 / ; through "I" and "K" %d97-105 / ; through "Z", both %d107-122 ; upper and lower case The timezones listed in the %timezones hash are obsolete timezones, per RFC 2822. Adding CEST (Central European Summer Time) means we should also add CET (Central European Time), and then why not all other abbreviations? There are a number of those, as can be seen by looking at https://en.wikipedia.org/wiki/List_of_time_zone_abbreviations Looking at the Wikipedia page above, we can also see that these abbreviations are ambiguous. For example, CST (one of the obsolete timezones listed in the RFC, and recognized by DateTime::Format::Mail) could mean any of: CST Central Standard Time (North America) UTC−06 CST China Standard Time UTC+08 CST Central Standard Time (Australia) UTC+09:30 CST Central Summer Time (Australia) UTC+10:30 CST Cuba Standard Time UTC−05 The RFC also states: Other multi-character (usually between 3 and 5) alphabetic time zones have been used in Internet messages. Any such time zone whose meaning is not known SHOULD be considered equivalent to "-0000" unless there is out-of-band information confirming their meaning. Although CEST and CET are unambiguous (at least according to the wikipedia page), it seems preferable to follow the RFC and its limited list of *obsolete* time zones. Therefore, the current behaviour (format a parsed CEST as -0000) is correct. However, the current (0.3001) version of DateTime::Format::Mail parses unknown timezones as "-0000", and uses that string for setting the timezone in the returned DateTime object. The issue is that DateTime understands "-0000" to mean UTC. So DateTime::Format::Mail incorrectly creates object with the UTC timezone when it encounters an unknown timezone, and incorrectly formats UTC as "-0000". See https://rt.cpan.org/Ticket/Display.html?id=94556 for details. The next release will properly set any unknown timezone as "floating" in the returned DateTime object, and properly format UTC as "+0000" and floating as "-0000". Regards, -- BooK