On 8/29/24 19:31, Riley O via NANOG wrote:
I've been fighting a similar issue. I'd like to throw in, a lot of mobile devices are geolocation dependent for time, and may completely disregard DHCP timezone and instead rely entirely on GeoLocation*even if it is woefully inaccurate, or unobtainable*.
Do we (operators of all sorts) know why they (big-buy mobile device manufacturers) do this? We know how unreliable network-based geolocation can be especially when there's a lack of network access. Presumably they are aware of this issue, too, and it seems glaringly obvious in the case where there's lack of the major network-based indicators they prefer to use (GPS, cellular, etc.). Worse, they seem to have made it difficult or impossible for us to do anything about it when it breaks despite effectively relying on our industry to make it work in the first place. Defaulting to nonsensical timezones (UTC, whatever country in Asia did the firmware, etc.) seems like the worst possible outcome in most cases. Just keeping the old timezone and using the (however inaccurate) onboard RTC seems like a far better situation in absence of all usable data. I'd also be inclined to trust the DHCP-provided timezone if I had no way to other way verify it it, and if you have enough network access to get that, you probably have access to NTP to get good universal civil time as well. I'm sure the high-level application has no notion of "my time is probably bogus" given that even most mainstream OSes don't handle it well at that level of the software stack, but they seem to have chosen the worst possible way to handle that at the lower levels. FWIW, my desk IP phone (which is like 15-20 years old) picks up the timezone from DHCP and time from (S)NTP exactly how you'd want it to. I think it was even the default setting, but it has readily-accessible knobs to configure that behavior if it's doing the wrong thing. -- Brandon Martin