Daylight savings time change

[RomanHK]

So what were the steps to test it?
I would have thought ntpd would take care of that side.

When I enter the date command, the time is correct, but the kernel is down. To do this, I need to use the date -k command. ntpd should, but not sync the kernel.

Step by step:

1) Set the rule by @ispyisail (I need to adjust it to my GMT+1 time zone):


2) Router default time zone:


3) Set date via ssh using commands:

Code: Select all

date 2019-03-31
date 1:59
date -k

Result:

Code: Select all

root@Gargoyle:~# date
Sun Mar 31 01:59:05 CET 2019
root@Gargoyle:~#

The Internet works.

Code: Select all

root@Gargoyle:~# date
Sun Mar 31 03:02:09 CEST 2019
root@Gargoyle:~#

root@Gargoyle:~# /usr/bin/set_kernel_timezone
root@Gargoyle:~#

The Internet works, but he shouldn't go.

4) Set date via ssh using command:

Code: Select all

date -k

Result:

Code: Select all

root@Gargoyle:~# date
Sun Mar 31 03:29:09 CEST 2019
root@Gargoyle:~#

Internet is not working. Here the status has changed.

ntpd still running:

Code: Select all

root@Gargoyle:~# ps | grep ntpd
10435 root      1064 S<   /usr/sbin/ntpd -n -N -l -S /usr/sbin/ntpd-hotplug -p
11544 root      1064 R    grep ntpd
root@Gargoyle:~#

[Lantis]

I could reproduce the behaviour, but... i could also find situations where it behaved completely normally.

I couldn't lock down exactly when each scenario would happen, but it looks like if the first thing that the router does after power-on (any time in the future, not just immediate) is a clock forward event, it appears to work ok.
If it first goes backwards, and then goes forwards later, this seems to fail.
This seems to be particularly bad for any timezones which are UTC negative (i.e. they will always go backwards after booting).

Anyway, i've changed the way set_kernel_timezone works slightly, and this seems to work a bit more reliably.
Are you at the point where you can build your own firmware @RomanHK? If so, if you could build my fix and see if you can still reproduce the bug that would be great.

In my testing, if you set the time too close to the changeover date/time, it doesn't switch immediately. However the cronjob that runs at 1 minute after the hour should subsequently catch it. Or invoking the tool manually if you are testing of course.
https://github.com/ericpaulbishop/gargoyle/pull/814

[RomanHK]

Are you at the point where you can build your own firmware @RomanHK?

Unfortunately, I don't know how to compile, I don't even have linux (ubuntu, ...) and I don't use VM (VirtualBox, ...).
I don't know how compilation works, but a new compiled binary would be enough for me to download and run it in a router to test functionality.

With the transition summer/winter time is always a problem (it is long-term) and it's not just here. The European Union's proposal is to unite under one and I fully agree with it. The nearest date is set at 2021 so far.

[Lantis]

Which router are you using to test? I have an ar71xx library built but it will only work on 1.11.x

[RomanHK]

Which router are you using to test? I have an ar71xx library built but it will only work on 1.11.x

Turris Omnia (mvebu) with 1.11.x

[Lantis]

http://lantisproject.com/gargoyle_mvebu/
I've included the library. It goes under /usr/lib/

[RomanHK]

Yes, I confirm, it works. I tried winter/summer and summer/winter time, after copying the library and entering the command "/usr/bin/set_kernel_timezone", everything behaved correctly. +1

[chrispeddler]

Have you checked your desktop clock? Maybe it is not synchronized...just a thought.

[gsuresh2u]

I am using 1.12 in Linksys WRT1900ACS
Upgraded from 1.10, not preserved any settings
Date and time is always nightmare to me
I tried these from above posts

Code: Select all

date 2020-07-11
date 1:59
date -k

When I restart router, it's going to default settings
What may be the problem?
Anybody please help me

[Lantis]

Set the timezone via the GUI.
Then allow the NTP client to sync your time as needed.

Unless you have a router that does not have internet access, there should be no need to manually set the time for 99% of use cases