Possible NTP corruption

[AmigaDude]

Has anyone experienced strange time entries?  Unfortunately I rebooted to straighted it out before I saved anything.

CurrentLocalTime was gibberish, like 1/2031/34938 or some such.  The last Call History entry was similar.  After the reboot, the CurrentLocalTime is corrected but I still have:

Call History:

Code Select Expand

Call 8 02/07/2036    02:21:31 
Terminal ID GoogleVoice2 PHONE1
Peer Name +15194328922 
Peer Number 15194328922 
Direction Inbound Inbound

[OBi-Guru]

Seen this in the past, likely due to NTP server not responding in time to the OBi request.
Please upgrade the OBi the latest firmware (1892) - think this problem has been fixed.

[AmigaDude]

ThankX,

But I was already running 1892 when I noticed the problem.  If it reoccurs I'll make sure that I save as much info as possible.  Not a big deal, just a little strange when you see it.

Now that I think about it, I did have my Internet router down for 5-10 minutes.  When I brought up the Obi page (just to make sure my Lan was still up) I noticed that SP1/SP2 Service Status was in a DNS NOT Responding state, or something like that.  It is possible that a NTP update was trying to occur and got corrupted around the same time.

[plugger2]

I was getting the nonsensical date problem under build 1892. It seems it was due to a firewall problem, possibly blocking port 123. In any case, things started becoming more reliable in this regard once I placed the OBi 110 in the DMZ.

There still appears to be a bug with the Local Timezone calculation however... to get my correct local time, which is GMT+10 (Sydney, Australia), I have to enter GMT+9 (Tokyo, Japan). And it's not a DST calculation error, either... this occurs consistently with DST enabled or not. Oh well. Not a biggie for a workaround as far as these things go, but ti would nice to get it fixed at some stage. Don't know if the bug applies to all timezones, or only some.

[OBi-Guru]

We confirmed the Time Zone problem for Sydney, and will make the correction on the next firmware update, adding Adelaide as well.   
However, for your current setting, given that it is now DST in Sydney, the correct selection for you should be GMT+10 (Sydney) with DST disabled to compensate for 1 hour difference (uncheck the default DST-enable parameter).

[Thunderbird1]

We confirmed the Time Zone problem for Sydney, and will make the correction on the next firmware update, adding Adelaide as well.   
However, for your current setting, given that it is now DST in Sydney, the correct selection for you should be GMT+10 (Sydney) with DST disabled to compensate for 1 hour difference (uncheck the default DST-enable parameter).

I've just done a bit of testing and it appears that the actual off-set for every entry from GMT+09:00(Tokyo,Seoul) onwards is out by 1 hr:

• GMT+09:00 = 10 hr off-set.
• GMT+10:00 = 11 hr off-set.
• GMT+11:00 = 12 hr off-set.
• GMT+12:00 = 13 hr off-set.

Since plugger2 is in Queensland, which doesn't observe DLS, his current work-around using +09:00 displays the correct time.

In http://www.obitalk.com/forum/index.php?topic=130.msg426#msg426 I made a suggestion to which I got no response so I'll repeat it here - and that is to consider adding either a generic off-set list from -12:00 to +12:00 in half hour increments or a 'user defined' field for manually entering a time offset.

This would then also cover places such as Lord Howe Island which uses UTC +10.30 for standard time and UTC +11.00 for daylight saving time - a 1/2 hr difference instead of the normal 1 hr difference. Norfolk Island use UTC +11.30 for standard time and don't observe daylight saving.

Seen this in the past, likely due to NTP server not responding in time to the OBi request.
Please upgrade the OBi the latest firmware (1892) - think this problem has been fixed.

This anomaly can be replicated by clearing the NTP server fields, saving and rebooting which confirms OBI-Guru's finding.

Would there be any merit in adding fields for manually entering a time & date? Haven't tested yet but what are the implications on call history date/time stamping of PSTN calls when internet connectivity is lost therefore also losing NTP server connectivity?

[OBi-Guru]

The drop down menu allows ease of use and does not quite fit with the style of adding hour/half-hour.
So with advanced apology to Lord Howe/Norfolk Islanders, we are not including your time zones.

[Thunderbird1]

Fair enough. Thanks for the confirmation.

[plugger2]

The drop down menu allows ease of use and does not quite fit with the style of adding hour/half-hour.
So with advanced apology to Lord Howe/Norfolk Islanders, we are not including your time zones.

Actually, while only allowing exact 1 hr offsets to GMT adversely affects Norfolk Island, it doesn't affect Lord Howe Island. So that's a win, I guess.

But it does adversely affect the whole of the state of South Australia, as well as the Northern Territory, including the capital cities of Adelaide and Darwin. Both SA and NT are in half-hour offset time zones. So you can chalk that up as a loss, I guess.

Seriously, how hard is this to make truly general? Sheesh.

(Rhetorical question, of course. I have experience in embedded software development, so I have a pretty good idea of exactly how difficult this would be to fix.)

[MichiganTelephone]

SOMEBODY has to mention it...     (source)

[OBi-Guru]

@plugger2: yes, Adelaide will be added on the drop down menu on the next release.

[Thunderbird1]

@plugger2: yes, Adelaide will be added on the drop down menu on the next release.

That will keep me happy