Daylight Savings Time Setting

[bluzfanmr1]

I didn't see this posted anywhere else. I noticed this morning that my router was an hour off. Turns out the default daylight savings time end date setting was incorrect for my GT-AX6000 and was listed as the 4th Sunday in Oct, so my router jumped back an hour.

I'm located in the Mountain Time Zone in the US and the setting should be the first Sunday in Nov at 2 am. I don't know if it's isolated to my newer router model but thought I'd let everyone know to double check this setting as I know it can sometimes cause issues when there is a mismatch and we're coming up on this change.

 

[jsbeddow]

This is nothing new: the exact settings for when DST starts/ends have always been set to a very "generic" example in the router firmware, as those dates vary a great deal around the world (if they even use DST at all), so Asus has not even attempted to keep up with this and program it to match or sync with time zones.

 

[EmeraldDeer]

 

[EmeraldDeer]

# nvram getall | 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

 

[jsbeddow]

My point was that it is easy to fix through the GUI, but it is up to every user to do so (manually, it won't happen automatically by setting a time zone).

 

[bluzfanmr1]

The 2 GT-AX6000 routers I manage were off. The old RT-AC66U_B1 had the correct default setting.

The point was to check your router for your area.

 

[Crimliar]

I could well be wrong about this!
I was under the impression that system time stamps are UTC and don't include any country or region adjustment. The only reason for the inclusion of the DST settings in the router is so that Text logs can be made to reflect the local "adjusted" time.

 

[RMerlin]

Asus regularly updates the DST database, however it does not automatically update whatever settings you have already applied if a DST changes. You have to re-apply your current timezone to apply the new start/end dates.

 

[jsbeddow]

Asus regularly updates the DST database, however it does not automatically update whatever settings you have already applied if a DST changes. You have to re-apply your current timezone to apply the new start/end dates.

I look forward to testing this out later: if this is the case, it is welcome news, as I have never seen any past evidence of corrections being applied accurately.

 

[bibikalka]

I ran into the same issue recently - parental control time settings were off.

 

[sfx2000]

Asus regularly updates the DST database, however it does not automatically update whatever settings you have already applied if a DST changes. You have to re-apply your current timezone to apply the new start/end dates.

And that db is only relevant with the SW/FW released at a particular time - it can change often enough...

 

[Crimliar]

So I take it that I'm wrong that the data distributed by the NTP server (local or remote) is in UTC, locale, localised time, and offset is not distributed?

 

[glens]

Offset is handled locally.

 

[ColinTaylor]

So I take it that I'm wrong that the data distributed by the NTP server (local or remote) is in UTC, locale, localised time, and offset is not distributed?

NTP has nothing to do with timezones. Local time is used for more than just log file timestamps. Think scheduled events like parental control, network services filer, reboots, etc.

 

[gk802]

I noticed the same DST time issue last week. I went into the GUI, corrected the DST start and end dates and applied the change. After doing so, I noticed that the system log had inconsistent timestamps on adjacent messages (some later messages had one-hour earlier timestamps) and that some cron jobs didn't run at the time expected. A system reboot solved the problem.