The problem with that approach is that it assumes that the system's UTC time is (approximately) correct already. While testing the implementation, that's almost always going to be true, and it would work for the cases where either the user is connecting to a remote system and wants to set their personal TZ to have times reflect their location, rather than the system's, and where a user with a laptop just got off the plane, and wants to set up their system to show local time for their current location. But I'd have thought those are relatively less frequent uses of tzselect - the more common usage would seem to be when installing a system, where nothing can be assumed about the system's clock at all, but local time (approximately) is known - in that case what usually happens is for the user to choose their timezone, then tell the system what the local time is, and for UTC to be deduced from that. Later, when the system is installed and running, NTP, or something equivalent can be used to refine the UTC setting, if it was roughly correct already. So I'd suggest (if this method is to be retained) that it come with a warning that it only be used if the system's UTC clock is already correctly set, which I do not know of any way to verify that can be expected to work during system installation (no network yet operating). kre