386.1 system time out by 1hr in Australia

[jata]

First of all massive thanks to @RMerlin for the 386.1 release. I have done a full factory reset and manual rebuild of my network to 386.1 and it is working amazingly.

The only (minor) issue I have found is that the system time and log entries are out by one hour and I have double checked settings are correct (exactly as setup with 384.19). I think the bug is that it is not adjusting system time for daylight savings although system says it is adjusted (i'm in Australia so it's summer here).

One interesting extra piece of information is that logging from the nextdns service/script is outputting the correct time.

can anyone else in southern hemisphere confirm/validate this issue?

 

[ColinTaylor]

Can you remove the "Release" tag from your title please as you are not announcing a new release of something. Thanks.

 

[jata]

Can you remove the "Release" tag from your title please as you are not announcing a new release of something. Thanks.

Done & apologies. Thought i was supposed to select this issue/question relates to the 'release' version.

 

[Treadler]

First of all massive thanks to @RMerlin for the 386.1 release. I have done a full factory reset and manual rebuild of my network to 386.1 and it is working amazingly.

The only (minor) issue I have found is that the system time and log entries are out by one hour and I have double checked settings are correct (exactly as setup with 384.19). I think the bug is that it is not adjusting system time for daylight savings although system says it is adjusted (i'm in Australia so it's summer here).

One interesting extra piece of information is that logging from the nextdns service/script is outputting the correct time.

can anyone else in southern hemisphere confirm/validate this issue?

Working fine here in Adelaide.
IMHO, it will be something in the daylight savings time settings causing the problem. (It needs to be manually edited, it's not automatic).

Pay particular attention to "starts", & "ends". "Starts" = later in the year for us.
Also, "hours". (Should = 1 I'm thinking.....)

 

[jata]

Working fine here in Adelaide.
IMHO, it will be something in the daylight savings time settings causing the problem. (It needs to be manually edited, it's not automatic).

Pay particular attention to "starts", & "ends". "Starts" = later in the year for us.
Also, "hours". (Should = 1 I'm thinking.....)

Thanks for the response. I have configured the starts and ends in the same way as 384.19 that worked fine. With exact same settings it is not correct on 386.1. Very strange.

Here are my settings.

but system time says it's 11am (but it is 12)

 

[Treadler]

Thanks for the response. I have configured the starts and ends in the same way as 384.19 that worked fine. With exact same settings it is not correct on 386.1. Very strange.

Here are my settings.

View attachment 30265


but system time says it's 11am (but it is 12)

View attachment 30266

Change your “hour(s)” fields to “1”.
They tell how many hours to add/subtract to get to/from DST.

 

[jata]

Change your “hour(s)” fields to “1”.
They tell how many hours to add/subtract to get to/from DST.

I will try but I do not think this is true. My understanding is that the config only tells the system when to shift the time by one hour. So in my config it happens at 2am when DST start and at 3am when it ends. I'm sure this is how it worked in 384.19.

Will report back to confirm... (ready to eat humble pie )

 

[jata]

so I made the changes and applied but it did not fix the issue. see below

1. system time one hr out from actual time
2. nextdns entry (circled) has correct time
3. log entries showing the syslog restarting but time does not change and it remains out by 1hr

 

[jata]

I have a workaround and identified the source of the issue.

This issue seems to impact only if you are using Sydney/Canberra/Melbourne as the timezone (GMT+10)

I changed timezone to Hobart (also GMT+10) and system time is now correct. Note if I change back to Sydney/Canberra/Melbourne the issue comes back.

So i think there is a error in the linux tzdata package which will probably fixed in a future release.

Hope this helps other OCD folks in using sydney/canberra/melbourne as their timezone

 

[Deleted member 51572]

Working fine here in Adelaide.
IMHO, it will be something in the daylight savings time settings causing the problem. (It needs to be manually edited, it's not automatic).

Pay particular attention to "starts", & "ends". "Starts" = later in the year for us.
Also, "hours". (Should = 1 I'm thinking.....)

on my AC86U, DST time zone changes were never configured correctly, despite selecting the correct Time Zone for my region. DST start & end dates can be looked up online and entered manually if you want the router to show the correct date and time.

actually, not just the AC86U, the AC1900P also suffers from the same DST bug. I've set the time zone to GMT-04:00 on both routers (running Merlin), but they both show the wrong DST end date (incorrect month and week). the correct dates, which change yearly, can be looked up and manually entered.

for example, i live in Halifax, NS (GMT-04:00). so I set the TZ to Atlantic Time (Canada), then manually set the DST start & end dates as shown in the screen capture, highlighted in yellow.

 

[Deleted member 51572]

Change your “hour(s)” fields to “1”.
They tell how many hours to add/subtract to get to/from DST.

the hours field is the time at which DST changeover occurs, not the number of hours added or subtracted. in the example i posted above, 2 hours means the changeover to/from DST will occur at 2am.

 

[mbekahs]

I can confirm I have the exact same issue with firmware 386.1 on RT-AC68U. The workaround of setting Hobart timezone works as suggested.

 

[JR Godwin]

I can also confirm the same issue on firmware 386.1 on AX-86U, with GMT+12 Auckland, Wellington. I don't have a same country / region other option....the only other +12 is in Russia?....either way, Northern Hemi......or.....

hmmm....just realised the rules loaded for the DST on and off were for a Northern Hemi.....so I chose another time zone, then came back to my time zone and it updated to the correct rules. So, maybe something in the dirty upgrades between firmwares is what changed that? Because prior to the 386 move the time wasn't off.

 

[gattaca]

This hour off has been an issue since 384.18/384.19 as I had alter the TZ settings on my AC86U units. I think (cannot prove) it was related to dirty upgrades.

 

[dh99999]

This hour off has been an issue since 384.18/384.19 as I had alter the TZ settings on my AC86U units. I think (cannot prove) it was related to dirty upgrades.

I've recently done a clean install after a hard reset for both 384.19 and 386.1.

I only have the issue in 386.1

 

[jata]

I've recently done a clean install after a hard reset for both 384.19 and 386.1.

I only have the issue in 386.1

me too. No issue with 384 only 386