Menu
What's new
By:
Filters Better Search

That time of year again....DST

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Jack Yaz

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
 
@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.
 
ColinTaylor said:
@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.
Click to expand...
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 said:
Not surprising since I ported the code from Merlin :)
Can someone simply define what the problem is exactly? Not sure I followed the thread.
Click to expand...
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.
 
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:
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?
 
XIII said:
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?
Click to expand...
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)?
 
JIPG said:
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
Click to expand...
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:
EmeraldDeer said:
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
Click to expand...
Yes that's the bug, my second post on this thread states editing the values fixed it for me.
 
Jack Yaz said:
Yes that's the bug, my second post on this thread states editing the values fixed it for me.
Click to expand...
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:
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.
 
Going round in circles - I am in the UK and setting manually
Code: 
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
Code: 
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?
 
archiel said:
What am I missing / getting wrong?
Click to expand...
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:
archiel said:
Going round in circles - I am in the UK and setting manually
Code: 
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
Code: 
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?
Click to expand...
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
 
You must log in or register to reply here.

Similar threads

T
Gt-AX6000 manufacturing year
Replies
5
Views
501
JamesK
JamesK
F
VLANs on AIMesh nodes, is this feasible today?
Replies
4
Views
966
fulvion75
F
J
Diversion Diversion won't start
Replies
2
Views
286
dave14305
dave14305
M
Solved RT-BE96U internet connection issue
2
Replies
26
Views
820
margentieri152
M
RMerlin
Current plans regarding separate version branches
3 4 5
Replies
87
Views
15K
zay2u
Z
Similar threads
Thread starter Title Forum Replies Date
orudie VPN does not auto connect after primary WAN disconnects and Secondary WAN becomes active. When primary WAN reconnects again then VPN auto reconnects Asuswrt-Merlin 6
J SSID QR Code validity after hard reset but using same SSID Password when setup again? Asuswrt-Merlin 1
G ddns request error, please try again Asuswrt-Merlin 6
E PSA: Check your local DST settings for accuracy Asuswrt-Merlin 0

Similar threads

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

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

Members online

Total: 696 (members: 15, guests: 681)
Top