D-Link Forums
The Graveyard - Products No Longer Supported => Routers / COVR => DIR-655 => Topic started by: schmieg on November 03, 2011, 10:30:08 AM
-
When the 655 first came out, the DST settings didn't work. It appeared that subsequent firmware releases fixed this, but I just discovered a problem with 2.03NA. DST changes on November 6, which is the first Sunday of November. Ergo, the settings according to the docs should be "November, 1st, Sunday, 2:00AM." However, with this setting, the time changed on November 1 which was a Tuesday. I have changed my settings to "November, 2nd, Sunday, 2:00AM" and will see if that works this coming Sunday, but there is definitely a glitch.
-
Are you using an NTP server?
-
Yes, time.nist.gov.
-
I'd just like to confirm that I'm also now having this issue in addition to the other time rollback issue.
EDIT: It appears that this rollback was caused by the DST issue as 7 days have not passed since the last time rollback occurred.
-
It's its possible that the DST is causing this as it's possible that the FW may not have the new DST time settings established a while back. The new DST time settings allow for an extra week before everyone observed settings the time forward or back. Lets see what happens this sunday.
-
It's its possible that the DST is causing this as it's possible that the FW may not have the new DST time settings established a while back. The new DST time settings allow for an extra week before everyone observed settings the time forward or back. Lets see what happens this sunday.
Furry, the actual DST date changeover shouldn't matter as the firmware ostensibly allows you to set it to whatever is necessary. The problem seems to be that the firmware instructions tell you that you should set it to designate the first Sunday of November. The form on the Time tabe in Tools indicates that 1st indicates the week. The firmware should be written so that this is the first full week, but it appears that this is not the case. The unfortunate part of this is that we will have to manually adjust the setting every year to compensate for whether the indicated Sunday falls on the first of the month or some other date. At the very least, the documentation should be updated to show this problem; preferably, the firmware should be rewritten to coincide with the documentation.
-
Lets see what happens on Monday.
-
Well DST ended today and the time did not roll back an additional hour which indicates that the DST settings are indeed not functioning properly (at least I have the right time now lol).
-
My time rolled back properly last night with the setting for it to happen on the second Sunday in November.
As I said, either the docs need to be corrected to match the firmware or the firmware corrected to match the docs. The latter would be better as that would eliminate the need to periodically change the settings.
-
Is the DST check box selected on your routers? Mine is not and I use the NTP server address and just checked and the time is set correctly.
Probably you don't need the DST check box when using NTP.
-
Is the DST check box selected on your routers? Mine is not and I use the NTP server address and just checked and the time is set correctly.
Probably you don't need the DST check box when using NTP.
Thanks for the info, I"ll try that.
-
Let us know what you see please.
-
I've done what you have suggested and I still have the correct time :)
-
How about schmieg?
-
Is the DST check box selected on your routers? Mine is not and I use the NTP server address and just checked and the time is set correctly.
Probably you don't need the DST check box when using NTP.
Your statement doesn't compute. DST is now over, so the time server and the router should both be the same whether the box is checked or not. When DST is in effect, the time server doesn't know whether your area has DST in effect or not. Some parts of the country still don't use it and the time server should be referencing GMT with the router making the adjustments for time zone and DST.
-
If your using and NTP, then you don't need to have DST checked. The router will aquire correctly time from the NTP server in regards to your time zone.
-
If your using and NTP, then you don't need to have DST checked. The router will aquire correctly time from the NTP server in regards to your time zone.
What about those areas that do not universally adopt DST?
-
Then they wouldn't use DST. I believe DST is not enabled by default.
-
Furry, I may be dense (I'm an attorney, not an engineer), but it seems to me that your last two messages contradict themselves. The router needs to be set to the same time as the LAN so that the schedules set on the router match with the scheduled tasks on the LAN computers. If DST is not enabled, come March, the router will be one hour off regardless of whether it is linked to a time server or not. From now until March, it doesn't matter. The time server adjusts by subtracting five hours from GMT for my time zone and the router makes the additional hour adjustment according to the DST settings. EST is still five hours off GMT when DST is in effect, but LAN and local time are adjusted (I feel like we're discussing Einstein's relative time theory here <grin>).
I still return to my point that the documentation differs from the operation of the router. To make the router work seamlessly, the firmware should be reprogrammed to Month - # of full weeks - dat. Then, when it changes on the first Sunday of November, it wouldn't matter whether the date of that Sunday was November 1 or November 6. Right now, it does matter and you have to adjust the router settings accordingly.
-
For what I know and have experienced, I have not had to perform any adjustments on the router for DST for fall back and going forward when using NTP server addresses. The time zone has been set for where I live and thats it. I'll forward this to Dlink for there review.