Release RT-AC68U Firmware version 3.0.0.4.386.43137

[dave14305]

Asus fetches their TZ info from their website:

http://nw-dlcdnet.asus.com/plugin/js/tz_db.json

It was last updated in June.

But since it is an http call within the System page, it will fail if you’re using https when logging in to the GUI.

If it’s still wrong in that file, report it to Asus.

 

[Objects in Space]

Asus fetches their TZ info from their website:

http://nw-dlcdnet.asus.com/plugin/js/tz_db.json

It was last updated in June.

But since it is an http call within the System page, it will fail if you’re using https when logging in to the GUI.

If it’s still wrong in that file, report it to Asus.

Thanks for the information. After the Quick Internet Setup, I was still using HTTP in the GUI since I had not performed the steps of using HTTPS per the instructions from ASUS.

Therefore, the Quick Internet Setup should have retrieved the correct Time Zone to avoid the error "System time zone is different from your locale setting".

I looked at the file you linked and there is no discernable information for Central Time (US, Canada) or UTC-0600 that would indicate if the entries are correct.

"CST6_2": "",
"CST6DST_3": "M4.1.0/2,M10.5.0/2",
"CST6DST_3_1": "M4.1.0/2,M10.5.0/2",
"UTC6DST": "",
"UTC-6": "",
"UTC-6_2": "",
"UTC-6.30": "",

 

[dave14305]

Thanks for the information. After the Quick Internet Setup, I was still using HTTP in the GUI since I had not performed the steps of using HTTPS per the instructions from ASUS.

Therefore, the Quick Internet Setup should have retrieved the correct Time Zone to avoid the error "System time zone is different from your locale setting".

I looked at the file you linked and there is no discernable information for Central Time (US, Canada) or UTC-0600 that would indicate if the entries are correct.

"CST6_2": "",
"CST6DST_3": "M4.1.0/2,M10.5.0/2",
"CST6DST_3_1": "M4.1.0/2,M10.5.0/2",
"UTC6DST": "",
"UTC-6": "",
"UTC-6_2": "",
"UTC-6.30": "",

I use Merlin firmware, but I find that the factory default timezone settings are not the same as if I deselect and re-select my desired timezone on the System page.

There is also a flaw in the Asus logic when comparing timezones that was fixed in Merlin but may impact other (generally non-English locales). If you want to see what’s up, navigate to the System pages, open the browser Console window (usually by hitting F12) and enter the variable uptimeStr followed by enter. The firmware will compare the characters after the + or - sign as your timezone offset. If there are more than one + or - sign in the resulting string, problems can occur.

I don’t imagine this is an issue for CST/CDT, however.

Merlin fix:

webui: Fix timezone detection (#729) · RMerl/asuswrt-merlin.ng@440d5a2

Ignore text in parentheses which may include a dash in non-English languages and confuse the index logic. For example: "GMT+0300 (Itä-Euroopan kesäaika)" Fixes #726

github.com

 

[wouterv]

I liked to point out that Microsoft OS is able to correctly adjust for all the different DST settings for the entire world and Microsoft has released OS patches that adjusted the DST settings when appropriate.

The DST code is not that difficult if you code modularity properly across your product lines.

Hence, ASUS needs to spend some effort to update or rewrite the DST code as a function that can be called or use an internal SQLite DB. This function code or SQLite DB can then be used across all of their routers so it is a simple update to the function or the DB that be imported and used in each router's code base.

You try to compare two totally different products, different in al aspects and most of all the OS size.

 

[Objects in Space]

I use Merlin firmware, but I find that the factory default timezone settings are not the same as if I deselect and re-select my desired timezone on the System page.

There is also a flaw in the Asus logic when comparing timezones that was fixed in Merlin but may impact other (generally non-English locales). If you want to see what’s up, navigate to the System pages, open the browser Console window (usually by hitting F12) and enter the variable uptimeStr followed by enter. The firmware will compare the characters after the + or - sign as your timezone offset. If there are more than one + or - sign in the resulting string, problems can occur.

I don’t imagine this is an issue for CST/CDT, however.

Merlin fix:

webui: Fix timezone detection (#729) · RMerl/asuswrt-merlin.ng@440d5a2

Ignore text in parentheses which may include a dash in non-English languages and confuse the index logic. For example: "GMT+0300 (Itä-Euroopan kesäaika)" Fixes #726

github.com

Thank you again Dave.

I do not see any issues for CST/CDT in the uptimeStr if I understand your post correctly.

 

[dave14305]

Thank you again Dave.

I do not see any issues for CST/CDT in the uptimeStr if I understand your post correctly.

View attachment 36833

Not quite. Just enter it into the Console input window.

The offsets from uptimeStr and Date() should match (-0400 in my case).

EDIT: I think I'm answering a question that no one even asked. But useful if you ever see the message that your timezones don't match.

 

[Objects in Space]

You try to compare two totally different products, different in al aspects and most of all the OS size.

I did not articulate correctly. The simple point I was trying to make is daylight savings are known values and vendors have to make adjustments whenever the daylight savings change values.

Due to the various features offered in the ASUS routers, proper daylight savings values are necessary.

As you pointed out, one of the impacts of DST is on parental controls. Removing DST from the ASUS routers would cause users to complain that their parental controls do not adjust for daylight savings.

Of course DST impacts other features within the router like guest controls and timestamps for files stored on the AiDisk and AiCloud. There may be more examples or undesirable impacts within the code that we never see in the GUI.

In my post, I offered ideas for ASUS if they are not using modular programming techniques that would greatly simplify their work effort when a change is needed to daylight savings values.

Again, it should be noted that the changes to both start/stop DST that took effect for the US made back in 2007 to which ASUS changed the start date from April to March but did not change end date from October to first Sunday in November for over 14 years and counting.

I reread your post to make sure I was correctly understanding your objection to ASUS spending time on making DST value adjustments.

However due to the ASUS router features, proper daylight savings value adjustments are necessary and not optional.

 

[Objects in Space]

Not quite. Just enter it into the Console input window.
View attachment 36835
The offsets from uptimeStr and Date() should match (-0400 in my case).

EDIT: I think I'm answering a question that no one even asked. But useful if you ever see the message that your timezones don't match.

Thanks again for replying Dave.

Unfortunately my Chrome browser is behaving differently from your browser or I am doing something wrong.

Here the Console with an error message.

Here is my attempt to search for uptimeStr.

 

[dave14305]

Thanks again for replying Dave.

Unfortunately my Chrome browser is behaving differently from your browser or I am doing something wrong.

Here the Console with an error message.

View attachment 36836

Here is my attempt to search for uptimeStr.

View attachment 36837

You're not meant to search for it. Instead, enter it like a command at the > prompt in the lower part of the window.

 

[Objects in Space]

You're not meant to search for it. Instead, enter it like a command at the > prompt in the lower part of the window.

Thank you Dave for your patience and help.

Interesting both your screenshot and mine do not match the Time Zone offset in the GUI. I am guessing the console values and the GUI will match when DST ends this November 7th.

 

[Oleksandr]

Still cuts half the speed as a node. Factory reset, new wires do not help. Continue using the switch between nodes.

 

[bachastain]

The support site has Version 3.0.0.4.386.43137 for the RT-AC68U, but a 5 month old Version 3.0.0.4.386.43129 for the RT-AC66U B1. It's been a while so I thought I had better check. Is it still ok to rename the RT-AC68U firmware and load it in the RT-AC66U B1?

Thanks..

 

[wouterv]

The RT-AC1900U also stays behind at 43129.
With the very limited information from the release notes and no one reporting any enhancement (nor new bugs), I would not bother to upgrade the RT-AC68U variants until there is a formal release.