On Wed, Nov 1, 2017 at 9:56 PM, Tim Cross <theophil...@gmail.com> wrote: > > OK, thanks for the additional information. That helps a lot. > > We can now narrow down where the issue is. > > After having looked (only very casually) at some of the org date/time > related functions, I think there may be quite a few issues. I'm not > convinced the root cause is org-2ft converting to UTC, though I think > that change has probably revealed some of the issues. > > There does seem to be some inconsistency or lack of clarity regarding > some of these operations and it could well be that the switch to using > UTC is not the correct approach, but just switching back probably isn't > either What does appear to be required is increased consistency in some > of these functions or where/how they are used. .
Thanks. I think I have been harping a bit too hard on org-2ft, but indeed it seems to be a bit more systemic an issue. > To correctly fix this, I feel more analysis is warranted. I'm prepared > to look at this and present a summary and options, but it will have to > wait until after 21st when I start leave from work. It is a complex area > and perhaps my skills won't be up to it, but I should at least be able > to identify the main areas needing attention/decisions. My initial approach would be to do some refactoring here, especially among org-2ft, org-matcher-time, and org-parse-time-string, each of which calls the others in a cycle and each share a part of the logic for interpreting Org mode timestamps. I'm not familiar with refactoring FOSS code via mailed patches, nor if Org maintainers would welcome such patches, but I would be willing to do some refactoring here. > > Whether we should change back to non-UTC for time comparisons in the > meantime is not something I feel informed enough to make a call. It > really depends on the daylight savings time related issues affecting > clock tables and other functionality. This is probably something core > org maintainers will need to make a call on. > > Tim
