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*.

1. RFC4833 *presumes* that the DHCP server KNOWS where the client IS to begin with. 
2. RFC4833 provides no mechanisms for the client to validate that the time information sent to it is valid for its current location, or hasn't been tampered with. 

This is a pretty simple chicken / egg problem. If you need to know where the client is to give it the right time zone, by definition something has to know where the client is, so why not just use THAT for your location? 

It's also massively insecure , especially these days, to just trust that whatever TZ you got sent in DHCP is correct and wasn't manipulated or spoofed. Using that as an indicator for *location* is ..... yeah.... 

On Thu, Aug 29, 2024 at 7:32 PM Riley O via NANOG <nanog@nanog.org> wrote:

Greetings from up the mountain (Lee Hill),

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*.

The room being shielded from cellular and GPS, I would imagine removes the primary mechanism most devices use to locate themselves. In those cases, most devices won't fail back to normal timesetting standard practices, but instead just 'send it' and set the time to some obscure default based on zeroed location or hardcoded internals.

Our issue at our house has been a total lack of cellular coverage and odd dynamics of GPS in a forest/valley leading to our mobiles falling back to obscure manufacturer default timezones when they reboot up here. If my cell phone goes dead, it will ignore the internal RTC on power up, and briefly show 00:00 before syncing with a timeserver and settings it's timezone to EST, regardless of what it was set to before or what DHCP says is correct.


It's a real shame given our proximity to the NIST office. There are some really bright time folks over there, it might be worth your time to reach out to someone there. Surely someone at CU will know the right person :)

Thanks,
Riley C. O'Connor
ColoradoColo - AS17139
307.438.9253 - m32@cubit.sh


On Wednesday, August 28th, 2024 at 5:40 PM, J.R. Raith <raithjr@jila.colorado.edu> wrote:

>

>

> Hi All,
>

> I have a laboratory in my department which thinks it's in central Russia
> when using Apple Maps on macOS and iOS devices. (I've also seen it in
> Google Maps on macOS, which I assume is GMaps getting its location from
> the OS). The lab has also reported Bhutan, Malta, and the equally exotic
> Ohio. This room is a shielded from GPS and cellular signals, but may
> pick up neighboring Access Points. Step outside of that specific room
> and you're back in Colorado.
>

> Phones and laptops keep setting their timezone wildly wrong and we're
> having graduate students and faculty missing classes/meetings.
>

> I've tried swapping out the Access Point in the lab. I've tried dropping
> a pin in Apple Maps and reporting the location as incorrect, repeatedly
> and with separate devices.
>

> I started looking at geolocatemuch, but I'm not sure that's the problem
> in this instance. The NAT IP we come from shows proper location in
> infosniper.
>

> I'd love to chat with an Apple person about how to solve it.
>

> Wish I could get frequent flyer miles for this...
>

> Thanks,
> J.R. Raith
> _________________________________________________
> Network Administration & Desktop Support
> JILA Computing - University of Colorado, Boulder