That time of year again....DST

[Jack Yaz]

Disclaimer: I can see a fix is in 386.2 for DST and some timezones, so this may fix it. I'm not in a position to test the beta sadly. Can anyone from the UK on the 386.2 beta confirm?

RT-AC86U, 386.1

Clearly, DST shouldn't be enabled yet, but the router thinks it is:

 

[Jack Yaz]

Manually changing nvram and /etc/TZ as per https://github.com/RMerl/asuswrt-merlin.ng/issues/699 works

echo "GMT0DST,M3.5.0/1,M10.5.0/2" > /etc/TZ
nvram set time_zone_x="GMT0DST,M3.5.0/1,M10.5.0/2"
nvram commit

Hopefully it won't revert, but at least I can fix it up again until 386.2 releases

 

[ColinTaylor]

@john9527 Looks like your firmware suffers from this problem as well.

TBH this has never worked properly before so I've always set it manually in the GUI. Switching back to the "automatic" setting confirms the problem above.

 

[john9527]

@john9527 Looks like your firmware suffers from this problem as well.

TBH this has never worked properly before so I've always set it manually in the GUI. Switching back to the "automatic" setting confirms the problem above.

Not surprising since I ported the code from Merlin
Can someone simply define what the problem is exactly? Not sure I followed the thread.

 

[Jack Yaz]

From the Post in thread 'Asuswrt-Merlin 386.2 Beta is now available' http://www.snbforums.com/threads/asuswrt-merlin-386-2-beta-is-now-available.71038/post-672782

Looks like similar problems still exist

 

[john9527]

Not surprising since I ported the code from Merlin
Can someone simply define what the problem is exactly? Not sure I followed the thread.

Nevermind.....found the bug (for my fork - ASUS code). Looks like they changed things a bit on the later Merlin, so will need to look at that some more.

 

[ColinTaylor]

Nevermind.....found the bug (for my fork - ASUS code). Looks like they changed things a bit on the later Merlin, so will need to look at that some more.

Looks like it's just this AFAICT.

https://github.com/RMerl/asuswrt-merlin.ng/commit/35adc326cc1b54c771849a7a8a2df13a7d30eabe

 

[JIPG]

Following the advice of Jack Yaz, I copy here my post in other unrelated thread.

I have an RT-AX88U with Merlin FW 386.1_2, and I am located in Spain. Today, the router time is one hour more than it should (it seems that it has changed today to summer time, although I have defined to do it last Sunday of March):

Now it should be 18:53, but the router indicates 19:53:

Yesterday it was OK, and there is nothing in the syslog stating that time has been changed ...

This is my information from NVRAM:

# nvram show 2>/dev/null | grep time_zone
time_zone=MET-1DST_1
time_zone_dst=1
time_zone_dstoff=M3.5.0/2,M10.5.0/3
time_zone_x=MET-1DST

# cat /etc/TZ
MET-1DST

 

[XIII]

For me (also living in Europe) it says "Daylight savings time is enabled in this time zone." which is not true in reality.

The time is correct though (no hour difference). Maybe because I use a local NTP server?

 

[ColinTaylor]

Maybe because I use a local NTP server?

That shouldn't make any difference because NTP doesn't convey any timezone or DST information.

 

[JIPG]

For me (also living in Europe) it says "Daylight savings time is enabled in this time zone." which is not true in reality.

The time is correct though (no hour difference). Maybe because I use a local NTP server?

I am also using a (supposed) local NTP server (es.pool.ntp.org), but I have the time displacement. I which zone are you located (the router I mean)?

 

[john9527]

For me (also living in Europe) it says "Daylight savings time is enabled in this time zone." which is not true in reality.

The statement is really just stating if the time zone uses DST, not if it is currently active.

 

[john9527]

Looks like it's just this AFAICT.

Not on my fork....there it's a different bug.

 

[EmeraldDeer]

Following the advice of Jack Yaz, I copy here my post in other unrelated thread.

I have an RT-AX88U with Merlin FW 386.1_2, and I am located in Spain. Today, the router time is one hour more than it should (it seems that it has changed today to summer time, although I have defined to do it last Sunday of March):
View attachment 31969
Now it should be 18:53, but the router indicates 19:53:
View attachment 31970

Yesterday it was OK, and there is nothing in the syslog stating that time has been changed ...

This is my information from NVRAM:

# nvram show 2>/dev/null | grep time_zone
time_zone=MET-1DST_1
time_zone_dst=1
time_zone_dstoff=M3.5.0/2,M10.5.0/3
time_zone_x=MET-1DST

# cat /etc/TZ
MET-1DST

Odd how my east coast USA time_zone_x value is three comma separated fields including the values of time_zone and time_zone_dstoff.

# nvram getall 2> /dev/null | grep time_zone
time_zone=EST5DST
time_zone_dst=1
time_zone_dstoff=M3.2.0/2,M11.1.0/2
time_zone_x=EST5DST,M3.2.0/2,M11.1.0/2
# cat /etc/TZ
EST5DST,M3.2.0/2,M11.1.0/2

As @ColinTaylor suggested, NTP synchronizes to UTC everywhere while the timezone and daylight saving offsets are handled by the operating system. I don't know if this handled in BusyBox Linux or in the Asus code. Some operating systems have a timezone database with local updates delivered as OS updates.
Edit: By the looks of the code update referred to by @ColinTaylor timezone and daylight saving offsets are handled in the Asus code and /etc/TZ needs to include both time_zone and time_zone_dstoff
Edit: Would manually editing resolve the issue?

time_zone_x=MET-1DST,M3.5.0/2,M10.5.0/3

# cat /etc/TZ
MET-1DST,M3.5.0/2,M10.5.0/3

 

[Jack Yaz]

Odd how my east coast USA time_zone_x value is three comma separated fields including the values of time_zone and time_zone_dstoff.

# nvram getall 2> /dev/null | grep time_zone
time_zone=EST5DST
time_zone_dst=1
time_zone_dstoff=M3.2.0/2,M11.1.0/2
time_zone_x=EST5DST,M3.2.0/2,M11.1.0/2
# cat /etc/TZ
EST5DST,M3.2.0/2,M11.1.0/2

As @ColinTaylor suggested, NTP synchronizes to UTC everywhere while the timezone and daylight saving offsets are handled by the operating system. I don't know if this handled in BusyBox Linux or in the Asus code. Some operating systems have a timezone database with local updates delivered as OS updates.
Edit: By the looks of the code update referred to by @ColinTaylor timezone and daylight saving offsets are handled in the Asus code and /etc/TZ needs to include both time_zone and time_zone_dstoff
Edit: Would manually editing resolve the issue?

time_zone_x=MET-1DST,M3.5.0/2,M10.5.0/3

# cat /etc/TZ
MET-1DST,M3.5.0/2,M10.5.0/3

Yes that's the bug, my second post on this thread states editing the values fixed it for me.

 

[JIPG]

Yes that's the bug, my second post on this thread states editing the values fixed it for me.

Does this commit in 386.2 beta (https://github.com/RMerl/asuswrt-merlin.ng/issues/699) solve the issue for all time zones?. Some people have reported the problem in 386.2 beta, but maybe, they only needed to "refresh" that variable (time_zone_x) after the FW upgrade changing a couple of times the time zone in the GUI.

Although I understand the change, I still have a doubt: why not having the DST data added to the time zone in time_zone_x did trigger (just yesterday) the wrong time when it was OK before?.

The workaround is OK, but if we have to change it manually every time we do a reset or install a new firmware, it is a killer.

 

[john9527]

Update on DST on my LTS FORK

What I originally thought was a found bug, was really a 'working as designed' given the base code level. When the fork base was released, it did not contain data for the DST start/stop times for the time zones. It gave you the ability to set these via the 'Manually set daylight savings time' checkbox. But, this checkbox was really mislabeled. It is really an 'Enable daylight savings time' option. You MUST have this checked on the current Fork levels for DST to work. (I recently had added the start/stop data, so what is filled in should be correct, but you still must check the 'Manually set....' box.)

Alternatively, I've uploaded release 48D4 to my Development-Beta downloads. This will automatically enable DST if your timezone requires it. The 'Manually set...' checkbox has been removed in line with the current Merlin builds and it will display the current start/stop times for you to edit if needed.

The recent Merlin commit was not needed for the fork (it was fixing an introduced bug).

I tested using the London timezone and everything looks correct with either of the above solutions.

Thanks.

 

[archiel]

Going round in circles - I am in the UK and setting manually

admin@RT-AX88U-5050:/tmp/home/root# echo "GMT0DST,M3.5.0/1,M10.5.0/2" > /etc/TZ
admin@RT-AX88U-5050:/tmp/home/root# nvram set time_zone_x=GMT0DST,M3.5.0/1,M10.5.0/2
admin@RT-AX88U-5050:/tmp/home/root# nvram commit

But DST is still active and if I check

admin@RT-AX88U-5050:/tmp/home/root# nvram getall 2> /dev/null | grep time_zone
time_zone=GMT0DST_1
time_zone_dst=1
time_zone_dstoff=M3.5.0/1,M10.5.0/2
time_zone_x=GMT0DST

What am I missing / getting wrong?

 

[ColinTaylor]

What am I missing / getting wrong?

Did you apply any changes through the GUI (Administration - System) after issuing the nvram commands?

Try using quotes maybe:

# nvram set time_zone_x="GMT0DST,M3.5.0/1,M10.5.0/2"
# nvram get time_zone_x
GMT0DST,M3.5.0/1,M10.5.0/2
# date
Mon Mar 15 17:24:08 GMT 2021

 

[Jack Yaz]

Going round in circles - I am in the UK and setting manually

admin@RT-AX88U-5050:/tmp/home/root# echo "GMT0DST,M3.5.0/1,M10.5.0/2" > /etc/TZ
admin@RT-AX88U-5050:/tmp/home/root# nvram set time_zone_x=GMT0DST,M3.5.0/1,M10.5.0/2
admin@RT-AX88U-5050:/tmp/home/root# nvram commit

But DST is still active and if I check

admin@RT-AX88U-5050:/tmp/home/root# nvram getall 2> /dev/null | grep time_zone
time_zone=GMT0DST_1
time_zone_dst=1
time_zone_dstoff=M3.5.0/1,M10.5.0/2
time_zone_x=GMT0DST

What am I missing / getting wrong?

nvram set time_zone_x=GMT0DST,M3.5.0/1,M10.5.0/2 doesn't look to have stuck for some reason. I've just checked mine and it's still correct after my nvram commit from yesterday