Todays timeline off by one hour after switching to daylight saving time

[christian-ho]

• KOReader version: 2023.03
• Device: Kobo Clara HD

Issue

Today (the day after switching to daylight saving time) the "Today's timeline" view of the statistics plugin is off by on hour, i.e. showing the reading time one hour too early.

[Frenzie]

I can't confirm; it's on 13:32 for me. The time on the device is otherwise correct?

[poire-z]

I can confirm that :) Hopefully, we'll look at it only tomorrow, and the problem will be gone, and we'll tag that "can't reproduce" :) It will come up twice a year, and we'll have to remember to only check the day after and pretend we can still not reproduce it!

I guess it is because to get the "base/start" of the day, we take the time at 0h00, which is still in winter time (here in Europe), and everthing for that day is made relative to that timestamp, so the shift we see. Not sure it's easy or worth fixing :/ Pinging @weijiuqiao for thoughts.

@Frenzie : the time is correct, it's just that if you read a few pages, you'll get the black bar in daily view growing in the 12:00 line.

[weijiuqiao]

Honestly I don't quite understand how the change of time works because we don't do it in my country :) But I remember @poire-z had brought something like this up when we were adding this functionality in the first place. It was by shifting the anchor time a little bit IIRC. So can this be solved similarly? :)

[poire-z]

What I remember suggesting was that to get the current day, to not request the date for 0:00 but 3:00, so whether DST +1/-1, we are sure with 3:00 to get the current day. The cause of this issue is, I guess, we store unix/GMT timestamp, an integer - and in the code, we must only do substractions, like (timestamp_13h34 - timesttamp_0h00) / 3600 to get the "hour slot", and because of dailight saving time, timestamp_13h34 is actually 12h34 seconds away from 0h00, so we get slot 12 instead of slot 13. To solve the issue, we'd need to convert each timestamp thru the library (libc) that knows about timezones to know that timestamp_13h34 is actually really in the 13rd hour slot. So, complex, expensive, ugly :/

[christian-ho]

I wouldn't make a big fuss about it, if tomorrow everything is ok again. One can live very well with it I think. Especially it will be interesting also on 29 October, if you read two times between 2 and 3 o'clock in the morning.

[christian-ho]

So I checked the timeline again today, and everthings seems fine for today and yesterday. BUT: If I now look back at the days before Sunday, all the time bars there are shifted one line down (to one hour later).

[poire-z]

Indeed... Moreover, it depends on how you reach that day. if you go see Friday or Saturday directly via Calendar View, you don't get the same view as if you go to them from first opening Today's timeline and swiping to see previous days :/ (where I guess we do starttimestamp - 86400 when going to each previous day).

[poire-z]

@weijiuqiao : while you're at it :): May be this: https://github.com/koreader/koreader/blob/df9c2bcb7f9f1d3f60bfaad20996a2b029d5b584/plugins/statistics.koplugin/calendarview.lua#L763-L768 could be extended (or done in :setupView()) to verify and proper align the provided day_ts on a day start ?

May be this is the way to do it:

day_ts = os.time()
prev_day_ts = day_ts
for i=0, 6 do
    -- this:
    day_date = os.date("*t", day_ts)
    day_ts = os.time({
        year=day_date.year,
        month=day_date.month,
        day=day_date.day,
    })
    --
    print(os.date("%c", day_ts), day_ts, prev_day_ts - day_ts)
    prev_day_ts = day_ts
    day_ts = day_ts - 86400
end

./luajit test.lua

Tue Mar 28 12:00:00 2023 1679997600 6286
Mon Mar 27 12:00:00 2023 1679911200 86400
Sun Mar 26 12:00:00 2023 1679824800 86400
Sat Mar 25 12:00:00 2023 1679742000 82800    Here, we move less than 86400s because DST
Fri Mar 24 12:00:00 2023 1679655600 86400
Thu Mar 23 12:00:00 2023 1679569200 86400
Wed Mar 22 12:00:00 2023 1679482800 86400

(And depending on how/where we would do that, if we know the day_ts we get is somehow aligned on 0h00, do the +10800 trick, day_date = os.date("*t", day_ts + 10800).)

[weijiuqiao]

while you're at it :)

Surely I can take a look :)

[mergen3107]

@weijiuqiao Any news on this?

I am struggling to have a proper Dst switch on my Kindle Scribe.

1. KOReader's plugin for Time Sync synchronizes OK, but it is still 1 hour behind (it never switched).
2. I copied /usr/share/zoneinfo folder from Ubuntu MATE 22.04, then did tzselect and selected America/New_York. Then also added TZ='America/New_York'; export TZ to /etc/upstart/env and restarted.

None of these helped to make a proper switch. I think Kindle's UI uses its own time setting mechanism, which is a part of cvm (their proprietary Java VM).

Can KOReader take care of the Dst switch for reading stats and highilights? Basically, can KOReader have its own time to work with?

I don't care if Kindle's UI off in time, I solely read and operate in KOReader :D

Thanks!

[mergen3107]

So, replacing /var/local/system/tz by a soft link or just the binary of the /America/New_York tz file caused that I can no longer change the Kindle UI time in Settings, but it stayed in EST time instead of EDT time (so one hour behind than it should).

Somewhere along the experiments with tzselect KOReader picked up the correct time, although Kindle UI was still 1 hour behind. All good now, but I don't know why xD

[mergen3107]

I tried to change the soft symlink /etc/localtime to /usr/share/zoneinfo/America/New_York (after copying zoneinfo of course), but this has the same effect.

I finally figured it out some time later. Number 2 from here (https://github.com/koreader/koreader/issues/10248#issuecomment-2015646061) is enough. Command line date shows correctly (with proper EDT time zone):

Tue Mar 26 13:22:25 EDT 2024

KOReader understands this well.

Then I only need to set time in Kindle UI (for Kindle's UI to be in sync).

[weijiuqiao]

Sorry as I don't really understand how summer time works and am not really intended to figure it out. I'll have to leave this to someone else. Luckily it only affects two days of a year if I'm correct.