KF5: Parsing times with timezone abbreviations
kevin.kofler at chello.at
Mon Mar 31 19:35:09 BST 2014
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).
More information about the kde-core-devel