A poll of the UK SE community shows that 7 want it disabled and 3 want it enabled. Both groups felt it important to provide user documentation to enable/disable. ...Democracy in action - its a beautiful thing.

A poll of the UK SE community shows that 7 want it disabled and 3 want it enabled. Both groups felt it important to provide user documentation to enable/disable. ...Democracy in action - its a beautiful thing.

I would suggest that this be “OFF” by default. I am considering existing time sync solutions implemented in current solutions that my be impacted with this feature set to “ON” by default.

Leave if “OFF” by default; however, provide a simple applet to enable the user to change the default state.

Don

To clarify the control of this feature. Setting certain registry values exposes user interface on the Date and Time panel. Then the user can choose (via checkboxes) if he/she wants to sync to current time zone and if they want to see notification after time was updated. This synchronization is applicable to WAN networks only - not applicable to WLAN. I'm not sure, but I heard that some networks may not support this feature.

Did some testing with NITZ on the MC35 and I think it's a great feature and it makes sense to enable it by default on a consumer phone.  On our devices, however, I believe the feature should be provided, but disabled by default.  We're never going quantify all the use cases, so we should leave the decision to the user.  In our case, we found that although the time synchronization was of great benefit, having the timezone automatically set caused issues as the users crossed timezones multiple times in a single day, but needed to keep their timezone synchronized with their depot.  The best of all worlds would be to have 3 states: 1: NITZ disabled for those who use other methods (NTP?) 2:NITZ enabled, but don't set system time (maybe placing the info in a reg key periodically) 3:NITZ fully enabled for the consumer class user. In state 2, we could expose an API that allows the developer to retrieve the current network time and timezone.  Then the developer could decide whether to set the system time and/or timezone depending on his business needs. Setting the time could be arbitrary, but setting the timezone should not. Hayden Eastman Southeast TA

Are we talking about setting the Time or the TimeZone? It is true that WM 6.1 has the new Clock XML provisioning option. Is it that you are suggesting using? To set the Time (GMT) is different from setting the TimeZone (say BST) however. What happens if you are on the edge of a time zone (say England/France). It is way too easy to migrate in network terms but not in physical TimeZone terms. As Paul says, if you are using setting Time from the carrier the this option is not available from all carries. This will usually only set Time though (AFAIK) not TimeZone. Setting the Time to an company network server is often best anyway from a business point of view. After all that is what they need. Consistent company time which stays the same even if it drifts slightly from real (GMT) time. This can be achived with very little code and examples of this being used on our terminals have been around for a long time (pun intended). Richard LH

I really think we should take a lead from the MOTO Q  team and place this option in the settings for all phone enabled devices. That way it really does not matter what the default is, just so it is easy to switch!

WM 6.1 Network Time (NITZ): Automatically updates the time on a device when it moves into a new time zone or receives a Daylight Savings Time (DST) change from the cellular network. By default it's turned off on Moto cellular phones. It should have an option to turn it off/on by GUI. The rest may be handled by XML provisioning.

Hi Can you provide more information WLAN or WAN (GSM/CDMA?)?  How does it work? I have a command in SymSript to sync to GSM network time  i.e. when network attaches (forces modem power off/on to force).  But not all providers support the broadcast (nitz) when you attach i.e. Vodafone do, O2 do not. thanks

I assume this is a carrier-based feature that only works on WWAN not on WLAN. Is this correct? So, if a device is used sometimes on WLAN (whenever available) and other times on WWAN (when available and necessary), the time zone may not always be set automatically to the correct value. This may be OK, but it could also confuse customers and/or cause serious application issues. We have some customers who rely heavily on the device having the right local time, in order for applications to work as expected. If we turn this on by default, then we may need to provide an easy way to turn it off as well. For example, if a customer is staging a device with MSP to set the time zone (as many are today), it could be an unpleasant shock to have that time zone change unexpectedly due to WWAN roaming. Before we decide to turn it on by default, we had probably better make sure that we have thought through the way(s) in which it will be turned back off if needed. Providing a registry setting as the ONLY way to set this to a backward-compatible value is probably NOT a very friendly solution, especially if it means that customers may experience application compatibility issues as a result. I guess in my mind, having it on by default should be determined based on a combination of new value it offers AND what, if any, backward compatibility issues it creates.

What is the impact (if any) on carrier supported Network Integrated Time Zone?  Thanks

Enabled by default, with a reg key or switch of some kind to turn it off is needed.