KF5: Parsing times with timezone abbreviations

[Kevin Kofler]

David Jarvie wrote:
> They can't just be ignored for small countries, since they may contain a
> daylight savings time indication.

Except for one "evil" hour every year, a given local time with the date 
included is either necessarily DST or necessarily non-DST.

That said, sure, if we are about to look at the abbreviation anyway, we may 
just as well always do it.

Now for that BBC weather RSS issue, I figured out that it apparently always 
reports the pubDate (which is unfortunately not the real date&time the 
conditions are from, but the date&time the RSS was requested at) in the 
local time of the place, given in a format like +1100. (That's the offset 
for Sydney, at which I looked because of that Australian vs. US timezone 
ambiguity.) So we could probably work with that, and hope that the reported 
observation time is really always given in the same timezone as that pubDate 
(and that this does not change in the future, e.g. to a pubDate in UTC).

But what do we do with other sources using this (admittedly broken) type of 
timezone specification? There's even RFC-822 that specifies those 3-letter 
specifications as one of the allowed formats, but only for "UT"="GMT"=UTC 
and for the continental US time zones ([PMCE][SD]T). As a data point of what 
other implementations do with that, the BSD strptime actually tries to 
support RFC-822 completely if you pass "%z" (but does not support non-US 
three-letter abbreviations), the glibc one didn't bother at all last I 
checked (its "%z" supports only the +1100 type (ISO 8601) format).

        Kevin Kofler