Has anyone seen this recently? On several MC75 made on Spring 2011 in China, no matter which timezone you set, if you come back and check timezone, it is set to GMT+2 Minsk. And hence LocalTime is accordingly changed. This happens on both WM6.5 and WM6.1. It also happens after rebooting (either cold or warm), no need to get into time config screen: you see time changed on today screen. Interestingly, any other GMT+2 timezone seems to be respected. But once you change to another timezone, it changes to Minsk (likely because it is the first GMT+2 on the list). This seems to have nothing to do with SPR about NITZ and DST in Tijuana: this started to happen with fresh recently purchased new MC75.
MC75 set themselves to GMT+2 Minsk. NO NITZ involved, btw!// Expert user has replied. |
8 Replies
Fix suggested by Hema did work! I still do not understand why and how, but it worked. So I will make an act of faith about. Thanks!!!
Yes of course, thanks for the advice, but I always tell customers/partners to disable it. It is a best practice. Anyway, in this case, they have Cisco APs. By the way, they have checked 5 units out of 100 and none of them showed the problem. They tested them in Madrid. Issue is happening in Murcia, some 400 km away. They will send 4 of these 5 working units to Murcia (without disabling NITZ), plug Vodafone SIM and see what happens. Anyway, I find hard to believe that a problem raised by a wrong setting on the carrier can persist after cleanblanking the unit, powering off the modem and removing SIM. But... one never knows...
You wont believe this: Source of the isssue is undeniably NITZ I have to agree, but... Four terminals that could be properly set in Madrid were sent to Murcia, then had a Vodafone SIM installed. Vodafone is the only carrier (as far as I know) in Spain that performs NITZ. After a few seconds, time is wrongly changed and timezone set to GMT+2 Minsk. No way to change it manually. So the turned off the phone and even removed SIM card. Then is when strange things start to happen... Even without connectivity timezone cannot be changed. Even after several cold boots. Even after (yes!) a clean+blank boot!!! But here comes the weirdest thing of them all: after a couple of hours, MC75 allows changing timezone (without connectivity, of course!!!). They will try and test the above-mentioned patch and see what happens. I will let you know then.
JAM can you provide a RILdebug log with NITZ enabled this way we can see if NITZ message is recieved and possibly sent with wrong DST offset.
Thanks Herbert, but I do not have terminals with me. On the other hand, let me put it much simpler so we all understand NITZ has nothing to do with this issue: If SIM card is removed and/or modem is powered off, this problem keeps on happening. Customer is going to test 5 random fresh out-of-the-box units from the same order's shipment (out of about 100 total units), and see what happens. I will let you know then.
Fusion Auto Time Config enabled? (Fusion Menu, Options, System Options) Try unchecking it. If this solves the problem, the time is set incorrectly on the WLAN infrastructure.
Hi, Could you please try to install the fix posted for the SPR 20070. https://support.symbol.com/support/search.do?cmd=displayKC&docType=…... 0 227128135 I hope this will solve the issue. It works for WM 6.1 as well as WM 6.5.
Thanks Hema, but as I stated on the subject, NITZ is not involved. And in fix's description they say: " This software fixes the issue; SPR 20070 and 16795, in MC7596 devices local time is set incorrectly when in sync with NITZ provided from Service provider." Actually, NITZ was involved indeed at the beginning: Vodafone was setting SystemTime. We are in Spain, timezone is UTC+1 in winter and UTC+2 in summer. In Belarus (then especially in Minsk), timezone is UTC+2 in winter and UTC+3 in summer. So in Belarus they always are one hour ahead Spain. Since timezone cannot be changed from Minsk, when Vodafone was setting time via NITZ, LocalTime was wrong!! So we disabled NITZ, but then again timezone could not be changed from Minsk. Anyway, setting the right-wrong time (i.e, the right localtime but the wrong systemtime) allows the application to get the right time, so this silly workaround allowed the customer to start the rollout. I will test the fix, just in case, one never knows...