I've looked at automatically determining the local time zone offset from UTC a few times... and always considered jumping off a cliff to be a better option. Huge, unreliable, always changing boundary data bases... local anomalies due to political reasons... lotsa really boring testing and verification, etc. So, Heather just lets the user tell it what the local time zone and daylight savings time rule is. Ahhh, the sweet, sweet bliss of shuffling off a complex, error prone something onto the user... I did consider (if the user did not specify the time zone) to default it to assume every 15 degrees longitude was a 1 hour time zone. Sort of like Heather's algorithmic guess of the current leap second count (GPS-UTC time offset value) if the receiver / input device does not send a UTC offset value... it's not always right but is better than nothing. If it's not right the user can specify the correct value. Guessed values are shown on the screen in red, user specified values are shown in yellow, device supplied values are shown in white. Speaking of which, aren't we getting close to needing a new leapsecond... it's been a while since the last one?
---------------- > Maybe Lady Heather could use that to find local time (if she doesn't already do it). _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
