Daylight saving time breaks targets

[bnthn]

Hey, I've been importing entries from the last year into TT and created a weekly target for a specific tag when I noticed this:

On days (and therefor in timespans containing these days) which have a different amount of hours in them due to daylight saving time, e.g. 29.10.2023 in my case, the target does not get calculated in an intuitive way.

From Wikipedia:

The typical implementation of DST is to set clocks forward by one hour in either the late winter or spring ("spring forward"), and to set clocks back by one hour in the fall (North American English) ("fall back") or autumn (UK English) to return to standard time. As a result, there is one 23-hour day in early spring and one 25-hour day in the middle of autumn.

So by selecting a timespan containing one of these days with e.g. 25 hours, the target for this day will be something like 25/24 * the_expected_target (and 23/24 * the_expected_target for days with 23 hours). For example, if you set a daily target of one hour a day and go to this day, the actual target will be 25/24 * 1 = 1.0416666 which is 1 hour and 2.5 minutes.

I said its unintuitive since it's technically correct and to be kind of expected, but i would rather like it to be the same target on these days as on any other day in the year. Since this will be different days every year and maybe even different days corresponding to the timezone you live in, they could be tricky to find, even though im sure the datetime package could help here.

Let me know what you think and thanks for consideration (and the development of this app in the first place ✌️ )!

[almarklein]

That's an interesting find, thanks! I think you're right, and this is a rare case where we don't want to take the DST into account with the calculations 😄