In a couple of weeks, I will have some spare time and I am happy to look at the time related functions in org-mode to see if we can refactor them to make them a bit clearer and possibly more efficient. I would be hoping for input from the list as guidance experience has taught me that date/time stuff can often have some subtle corner cases which are easily missed.
regards, Tim Nicolas Goaziou <m...@nicolasgoaziou.fr> writes: > Hello, > > Allen Li <vianchielfa...@gmail.com> writes: > >> Alas, I still can't seem to find the original DST bug. I'm not sure >> using UTC solves DST problems. >> >> For example, in the timezone America/Los_Angeles, >> >> <2017-11-05 01:00:00> -> <2017-11-05 04:00:00> = 4 hours >> <2017-10-10 01:00:00> -> <2017-10-10 04:00:00> = 3 hours >> <2017-03-12 01:00:00> -> <2017-03-12 04:00:00> = 2 hour >> >> This is what Emacs gives me using the default time zone >> >> <2017-11-05 01:00:00> -> <2017-11-05 04:00:00> = 4 hours >> <2017-10-10 01:00:00> -> <2017-10-10 04:00:00> = 3 hours >> <2017-03-12 01:00:00> -> <2017-03-12 04:00:00> = 2 hour >> >> This is what Emacs gives me using UTC >> >> <2017-11-05 01:00:00> -> <2017-11-05 04:00:00> = 3 hours >> <2017-10-10 01:00:00> -> <2017-10-10 04:00:00> = 3 hours >> <2017-03-12 01:00:00> -> <2017-03-12 04:00:00> = 3 hours >> >> Using UTC seems strictly wrong to me. > > You're right. Using UTC doesn't solve any DST bug, despite what > I initially thought. I think we just need to remove the whole set of > changes about UTC in `parse-time-string'. We also need to adapt tests in > test-org-clock since the same time difference could have different > meanings depending on the time zone. I can do that later, if no one > objects. WDYT?n > > Refactoring time functions in Org is still useful, though. > > Regards, -- Tim Cross
