That time of year again....DST

Jack Yaz

Part of the Furniture
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

1615736467069.png


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

Jack Yaz

Part of the Furniture
Manually changing nvram and /etc/TZ as per https://github.com/RMerl/asuswrt-merlin.ng/issues/699 works
Code:
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 :)
 
Last edited:

ColinTaylor

Part of the Furniture
@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

Part of the Furniture
@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.
 

john9527

Part of the Furniture
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.
 

JIPG

Regular Contributor
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):
1615746507474.png

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


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
 
Last edited:

XIII

Very Senior Member
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

Part of the Furniture
Maybe because I use a local NTP server?
That shouldn't make any difference because NTP doesn't convey any timezone or DST information.
 
Last edited:

JIPG

Regular Contributor
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)?
 

EmeraldDeer

Very Senior Member
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.
Code:
# 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?
Code:
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
 
Last edited:

Jack Yaz

Part of the Furniture
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.
Code:
# 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?
Code:
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

Regular Contributor
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.
 
Last edited:

john9527

Part of the Furniture
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

Senior Member
Going round in circles - I am in the UK and setting manually
Code:
[email protected]:/tmp/home/root# echo "GMT0DST,M3.5.0/1,M10.5.0/2" > /etc/TZ
[email protected]:/tmp/home/root# nvram set time_zone_x=GMT0DST,M3.5.0/1,M10.5.0/2
[email protected]:/tmp/home/root# nvram commit

But DST is still active and if I check
Code:
[email protected]:/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

Part of the Furniture
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:
Code:
# 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
 
Last edited:

Jack Yaz

Part of the Furniture
Going round in circles - I am in the UK and setting manually
Code:
[email protected]:/tmp/home/root# echo "GMT0DST,M3.5.0/1,M10.5.0/2" > /etc/TZ
[email protected]:/tmp/home/root# nvram set time_zone_x=GMT0DST,M3.5.0/1,M10.5.0/2
[email protected]:/tmp/home/root# nvram commit

But DST is still active and if I check
Code:
[email protected]:/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
 

Similar threads

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top