emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] Bug: org-2ft and/or float-time is wrong [9.1.2 (9.1.2-22-ga2a034


From: Nicolas Goaziou
Subject: Re: [O] Bug: org-2ft and/or float-time is wrong [9.1.2 (9.1.2-22-ga2a034-elpaplus @ ~/.emacs.d/elpa/org-plus-contrib-20171023/)]
Date: Thu, 02 Nov 2017 10:35:58 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux)

Hello,

Allen Li <address@hidden> 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,

-- 
Nicolas Goaziou



reply via email to

[Prev in Thread] Current Thread [Next in Thread]