Kenwood DNX9280BT time issues

markrmifsud · Lifetime Member Joined: Sep 17, 2007 Posts: 39

Hi there, a strange new problem has just started on this unit.

If I set the Nav time = Auto then it is 1 hour out, ie displays 14:00 when it is 15:00
If I manually set the time to 15:00 then it displays 15:00 but the Nav seems to still use the incorrect time.

Setting to auto, set destination to 1 hour drive, it says eta is 1 hour earlier thanreal time. ie auto set is 14:00, current real time is 15:00 and it says I will arrive at 15:00

Set to Manual, 15:00, 1 hour drive eta is 15:00, similarly if I set a 30 min drive it will say ETA is 14:30.

I have played around back and forth with the time settings, also hard powered off the HU and a full reset, it still has the same error with the times.

Any ideas?

regards

Oldboy · Posted: Fri Jul 17, 2020 8:18 pm Post subject:

It seems like a GMT and GMT+1 problem. Are you able to set the time zone to GMT+1 in the settings?
_________________
Richard

TT 910 V7.903: Europe Map v1045
TT Via 135 App 12.075: Europe Map v1140

markrmifsud · Lifetime Member Joined: Sep 17, 2007 Posts: 39

Hi, no the options are
set HH:mm or set to auto

To add to this, if I look at the system time in World Clock settings, it shows as 4th Dec 2000. The days are updating and the actual mins are accurate.

I get an average 8 sats with 18ft accuracy and it shows my position accurately whilst driving so it is getting the GPS signals.

markrmifsud · Lifetime Member Joined: Sep 17, 2007 Posts: 39

That Garmin (some of) has its own Y2K bug that affects the date processing.

https://support.garmin.com/en-US/?faq=zWQY6Z2kFiAuY9kDnDBgZ6

M8TJT · Posted: Mon Jul 20, 2020 7:02 pm Post subject:

and 20 1/2 years later, it rears its ugly head. Very Happy

Kremmen · Posted: Tue Jul 21, 2020 4:25 am Post subject:

Would the Y2K bug affect it in this way ?

The Y2K bug was old memory restricted software where dates were just YYMMDD.

The issue arose when before or after comparisons were needed. In those days 990101 (1st Jan 1999) was higher than 981230 (30th Dec 1998) so all was well.

As soon as we crossed Y2K then 000101 (1st Jan 2000) wasn't greater than 991230 so hardware started having issues.

What we had to do was introduce a CC into the mix so 20000101 was greater than 19991230.

FYI Additional info:

Because date comparisons often included birth dates and given some were still working at 70 we had to perform the fix using dates up to 2030, some used 2020. This way a birthdate of 1930, or 1920 was correctly returned.

The software 'fix' said, if YY is greater than 30, or 20, then assume CC is 19 else CC is 20. Moving forward, for any old software still in existence, 2020 could be converted to 1920.

Some fixes used 50 as the cutoff so Y2K may still be an ongoing problem but new software correctly uses CCYYMMDD.
_________________
DashCam:
Viofo A119 V3

M8TJT · Posted: Tue Jul 21, 2020 9:29 am Post subject:

As the problem with OP's unit has only just started, I really can't imagine why we are even discussing the Y2K 'problem'. That was concerning dates, not time.
But OP's problem seems to be, pretty obviously, one of BST v GMT (or whatever you want to call them) as his device is displaying (and calculating on)GMT when it should be BST.

But other than that, I have absolutely no idea of what's CAUSING the problem. I would normally suggest a hard reset, but OP has already done that.

markrmifsud · Lifetime Member Joined: Sep 17, 2007 Posts: 39

Hi, I mentioned Y2K as a bit tongue in cheek as my system has rolled back to the year 2000 and the issue relates to date roll over..

It seems that my unit could not roll over to the new date after the 1024 week count reset.

According to Kenwood and an Authorised supplier there is no fix for this.

This link explains the issue better
https://www.rya.org.uk/newsevents/news/Pages/GPS-week-number-rollover.aspx?gclid=EAIaIQobChMI1vCelpXc6gIVjql3Ch3NwwJBEAAYASAAEgL5RPD_BwE

	PocketGPS
	Web