#3890: mutt_mktime is ambiguous near DST change
---------------------+----------------------
Reporter: vinc17 | Owner: mutt-dev
Type: defect | Status: new
Priority: major | Milestone:
Component: mutt | Version: 1.7.1
Resolution: | Keywords:
---------------------+----------------------
Comment (by derekmartin):
OK I see, but as I've already pointed out, Mutt still won't be able to get
this right in the overwhelming majority of cases, because the required
information is simply unavailable. For instance, in is_from() (in from.c)
it's NOT POSSIBLE to get this right, because in general there is no
indication of whether or not DST is in effect in the date in the from
line. Likewise in the headers, the time zone need only be represented as
the offset from GMT; the symbolic time zone may or may not be present.
A cursory examination of my mail indicates the time zone info is NEVER
present on the From line, and in the date field it is by far the majority
of cases that it is not presented with any indication of DST. I guess we
can get it right in the minority of cases where it IS available...
Basically, parse.c is the only place this matters, I believe. In all
other cases Mutt can set isdst = -1 but this doesn't really help in the
broken case.
You can perhaps improve the chances of getting it right by parsing the
Received headers... but this is not guaranteed (since often the important
received header is spoofed, or in a different time zone than the sender,
or otherwise insufficient). And it seems like an awful lot of trouble to
go through for an oddball edge case that is very unlikely to occur anyway
(since at 2am most people are sleeping, and it only happens 1 hr a year).
I think this isn't worth the effort, and should be closed WONTFIX.
I believe, FWIW, that there are worse problems... Basically anywhere that
mutt_mktime() is called and local=0, it's assumed that the date is a GMT
time, which as best as I can tell is generally not the case. In some
cases this is fixable (because the time zone is actually available) but in
others it's not. When the time zone is available, Mutt would need to
convert that essentially to a pair of (offset, is_dst) in order to get the
time right, but unless the symbolic form of the time zone is given (which
we've already established that it mostly isn't) there's no good way to do
that, AFAIK. In particular, Mutt can't practically maintain its own
database of the world timezones, and I don't see any portable way to
manipulate the system's timezone database other than mktime(),
localtime(), and their various friends... none of which get you what you
need, AFAICT, since they require the DST flag as input.
--
Ticket URL: <https://dev.mutt.org/trac/ticket/3890#comment:9>
Mutt <http://www.mutt.org/>
The Mutt mail user agent
