Allen Li writes:
> On Wed, Nov 1, 2017 at 9:56 PM, Tim Cross wrote:
>>
>
>> 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 are
Allen Li writes:
> ...
> 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.
>
See http://orgmode.org/worg/org-contribute.html
--
Nick
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 st
Hello,
Allen Li 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
On Wed, Nov 1, 2017 at 9:56 PM, Tim Cross 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
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,
Sorry for the spam, but I am digging to see how deep the rabbit hole goes.
All five of the first branches in org-matcher-time are wrong (again,
local timezone dependent):
(org-time= "<2017-11-01>" "")
nil
(org-time= "<2017-10-31>" "")
nil
(org-time= "<2017-11-02>" "")
nil
(org-time= "<2017-11-02>
I found another one (It is 2017-11-01 in local time for me)
(org-time= "<2017-11-01>" "")
nil
This is also local timezone dependent.
Tim made the point that these floats are not intended to be Unix
timestamps and only used for comparison, but this implementation
detail leaks quite heavily. Furt
On Wed, Nov 1, 2017 at 8:27 PM, Tim Cross wrote:
>
> I get that, what I am not clear about is where you encounter this issue
> when using org .eg. is it when entering now as a date for generating an
> agenda of past or current scheduled items etc or is this a problem with
> some custom functions y
Allen Li writes:
> On Wed, Nov 1, 2017 at 5:09 PM, Tim Cross wrote:
>>
>> Let me try to clarify and see if that helps.
>>
>> Org is only forcing time into UTC format for functions which deal with
>> time comparisons. i.e. those which use org-2ft. The reason for doing
>> this is to try and avoid
On Wed, Nov 1, 2017 at 5:09 PM, Tim Cross wrote:
>
> Let me try to clarify and see if that helps.
>
> Org is only forcing time into UTC format for functions which deal with
> time comparisons. i.e. those which use org-2ft. The reason for doing
> this is to try and avoid issues relating to daylight
Let me try to clarify and see if that helps.
Org is only forcing time into UTC format for functions which deal with
time comparisons. i.e. those which use org-2ft. The reason for doing
this is to try and avoid issues relating to daylight savings timezone
changes when performing comparison operati
On Wed, Nov 1, 2017 at 1:55 PM, Nicolas Goaziou wrote:
>
> IIRC, the point is to remove DST in durations, i.e., in the difference
> between two dates. One way to do that is to assume UTC in both start end
> end date. Most of the commits are about making sure UTC is used whenever
> two Org dates ar
Hello,
Allen Li writes:
> I guess the relevant bug is
> http://lists.gnu.org/archive/html/emacs-orgmode/2017-07/msg00097.html,
FWIW, this is not the initial bug.
> From what I can glean from the history,
> 112c5ba479d52c3c36de5c7aafd14ab6bc075005 is where things started to go
> wrong. UTC tim
Apologies, my reply was partially omitted. My full reply follows
On Wed, Nov 1, 2017 at 6:09 AM, Tim Cross wrote:
>
> Allen Li writes:
>
>> On Wed, Nov 1, 2017 at 12:18 AM, Tim Cross wrote:
>>>
>>> My preferences would be
>>>
>>> 1. If a timestamp does not include the TZ, then assume the local
On Wed, Nov 1, 2017 at 6:09 AM, Tim Cross wrote:
>
> Allen Li writes:
>
>> On Wed, Nov 1, 2017 at 12:18 AM, Tim Cross wrote:
>>>
>>> My preferences would be
>>>
>>> 1. If a timestamp does not include the TZ, then assume the local TZ
>>> 2. If a timestamp does include the TZ, honour that TZ
>>
>>
Allen Li writes:
> On Wed, Nov 1, 2017 at 12:18 AM, Tim Cross wrote:
>>
>> My preferences would be
>>
>> 1. If a timestamp does not include the TZ, then assume the local TZ
>> 2. If a timestamp does include the TZ, honour that TZ
>
> Org mode does not support TZ in time strings and adding suppo
On Wed, Nov 1, 2017 at 12:18 AM, Tim Cross wrote:
>
> My preferences would be
>
> 1. If a timestamp does not include the TZ, then assume the local TZ
> 2. If a timestamp does include the TZ, honour that TZ
Org mode does not support TZ in time strings and adding support isn't
the topic of the curr
My preferences would be
1. If a timestamp does not include the TZ, then assume the local TZ
2. If a timestamp does include the TZ, honour that TZ
3. If the timestamp does not include a time component, default to 0:00:0
for the local TZ
4. org-2ft should not enforce the UTC TZ. I agree this is inc
On Tue, Oct 31, 2017 at 10:41 PM, Tim Cross wrote:
>
> I think this whole issue really requires a lot more analysis and
> design. Just removing or cancelling various commits is unlikely to
> improve matters and could result in new problems.
You're right, but the new behavior was introduced fairly
I think this whole issue really requires a lot more analysis and
design. Just removing or cancelling various commits is unlikely to
improve matters and could result in new problems.
For org to work correctly, especially when interacting/interfacing with
other systems, such as external calendars,
On Tue, Oct 31, 2017 at 11:52 AM, Nicolas Goaziou
wrote:
> Allen Li writes:
>
>> Can you clarify on the issues the UTC timezone fixes?
>
> At the moment, I can only give you a pointer, which is commit
> 97a1a498956da2e1961df5a0506df4cbb98fff52. Some other commits followed
> this one in maint and
Allen Li writes:
> Can you clarify on the issues the UTC timezone fixes?
At the moment, I can only give you a pointer, which is commit
97a1a498956da2e1961df5a0506df4cbb98fff52. Some other commits followed
this one in maint and master.
You may want to check the ML for the initial bug report.
Re
On Tue, Oct 31, 2017 at 11:23 AM, Nicolas Goaziou
wrote:
> Hello,
>
> Allen Li writes:
>
>> Removing the t for zone fixes it
>
> [...]
>
>> I will also note that the FIXME comment in org-parse-time-string
>> suggests that it too is not handling timezones correctly. In fact,
>> perhaps org-parse-
Hello,
Allen Li writes:
> Removing the t for zone fixes it
[...]
> I will also note that the FIXME comment in org-parse-time-string
> suggests that it too is not handling timezones correctly. In fact,
> perhaps org-parse-time-string should not take a zone argument, since
> Org does not suppor
On Mon, Oct 30, 2017 at 5:40 PM, Allen Li wrote:
> (current-time-string (time-to-seconds (org-2ft "<2017-10-31>")))
> "Sun Oct 29 17:00:00 2017"
>
> This seems wrong
>
> In org-2ft
>
> (org-parse-time-string s nil t)
>
> The t means use UTC instead of Emacs local time.
>
> However, Org translates
26 matches
Mail list logo