Swiss time selectable for Germany
Hi, I tried tzselect for Germany and was presented with following question: Please select one of the following timezones. 1) Swiss time 2) Germany (most areas), Scandinavia We do not use Swiss time in Germany. I did some research: Germany switched to summertime in 1980 and Swiss in 1981. There is Büsingen am Hochrhein which followed Swiss and therefore deviated from Germany only in 1980. Should zone1970.tab reflect the current status (i.e. drop DE from Europe/Zurich and rename "Germany (most areas)" to "Germany" in the comments)? -- Benjamin Drung Debian & Ubuntu Developer
On 2023-01-06 16:26, Benjamin Drung via tz wrote:
We do not use Swiss time in Germany.
I installed the attached to try to make that a bit clearer.
Should zone1970.tab reflect the current status
No, as zone1970.tab partitions the world into regions that agree from 1970 through the foreseeable future. It would make sense to have another file 'zonenow.tab' that would partition the world into regions that agree from now through the foreseeable future; this would have fewer regions than zone1970.tab, just as zone1970.tab has fewer regions than zone.tab. zonenow.tab would benefit users who don't care about past timestamps, since they'd have fewer timezones to choose from and so could avoid some confusion. It wouldn't need to mention Europe/Zurich, for example, so this whole business of Büsingen vs the rest of Germany would vanish.
A separate zonenow.tab makes it (relatively) easy to add an option to tzselect that only presents current zones. (Alternatively, the existing mechanism of specifying the zone table with an environment variable can be sued.) @dashdashado --ado On Fri, Jan 6, 2023 at 8:03 PM Paul Eggert via tz <tz@iana.org> wrote:
On 2023-01-06 16:26, Benjamin Drung via tz wrote:
We do not use Swiss time in Germany.
I installed the attached to try to make that a bit clearer.
Should zone1970.tab reflect the current status
No, as zone1970.tab partitions the world into regions that agree from 1970 through the foreseeable future.
It would make sense to have another file 'zonenow.tab' that would partition the world into regions that agree from now through the foreseeable future; this would have fewer regions than zone1970.tab, just as zone1970.tab has fewer regions than zone.tab.
zonenow.tab would benefit users who don't care about past timestamps, since they'd have fewer timezones to choose from and so could avoid some confusion. It wouldn't need to mention Europe/Zurich, for example, so this whole business of Büsingen vs the rest of Germany would vanish.
On 2023-01-07 09:02:17 (+0800), Paul Eggert via tz wrote:
On 2023-01-06 16:26, Benjamin Drung via tz wrote:
We do not use Swiss time in Germany.
I installed the attached to try to make that a bit clearer.
This patch (consistently) misspells "Liechtenstein". Other than that, this seems like a good idea. Philip -- Philip Paeps Senior Reality Engineer Alternative Enterprises
On Fri, 2023-01-06 at 17:02 -0800, Paul Eggert wrote:
On 2023-01-06 16:26, Benjamin Drung via tz wrote:
We do not use Swiss time in Germany.
I installed the attached to try to make that a bit clearer.
Thanks. Could you add " (Germany)" to Büsingen? It is too small to be commonly known in Germany.
Should zone1970.tab reflect the current status
No, as zone1970.tab partitions the world into regions that agree from 1970 through the foreseeable future.
It would make sense to have another file 'zonenow.tab' that would partition the world into regions that agree from now through the foreseeable future; this would have fewer regions than zone1970.tab, just as zone1970.tab has fewer regions than zone.tab.
zonenow.tab would benefit users who don't care about past timestamps, since they'd have fewer timezones to choose from and so could avoid some confusion. It wouldn't need to mention Europe/Zurich, for example, so this whole business of Büsingen vs the rest of Germany would vanish.
+1 for a zonenow.tab file. -- Benjamin Drung Debian & Ubuntu Developer
On 2023-01-07 01:53, Benjamin Drung via tz wrote:
Thanks. Could you add " (Germany)" to Büsingen? It is too small to be commonly known in Germany.
I looked into how that string is used, came up with what I hope is a better idea, tested it, and fixed another glitch or two that I found. The idea is that zone1970.tab's comment column should cover only countries that have multiple timezones, so that it needn't worry about summarizing all the other countries (which don't need the summary anyway). I installed the attached patches to implement this. With it, if you run tzselect and choose Germany, you see: Please select one of the following timezones. 1) Büsingen enclave 2) Germany (most areas) which I hope is good enough in the context where you've already picked Germany. It's OK when someone who runs tzselect doesn't know about Büsingen, as they should just shrug and pick the "most areas" line. Patch 1 implements this change. Patch 2 shortens the TF comment so that if you run tzselect and pick Asia, the prompt still fits on a 24×80 screen (it ballooned in 2022b). Patch 3 improves tzselect so that it takes advantage of the Patch 1 change. This change improves behavior both with older and bleeding-edge tzdata. Older tzselects will still work, though their (already-confusing) messages will be perhaps a bit more confusing in some cases. I hope this tzselect improvement migrates into Ubuntu soon. Patch 4 fixes a glitch related to Johnston Island that I found while testing.
Paul Eggert via tz said:
I installed the attached patches to implement this. With it, if you run tzselect and choose Germany, you see:
Please select one of the following timezones. 1) Büsingen enclave 2) Germany (most areas)
Should "most areas" be "all other areas"? -- Clive D.W. Feather | If you lie to the compiler, Email: clive@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646
On 2023-01-07 13:51, Clive D.W. Feather wrote:
Should "most areas" be "all other areas"?
Sure, I installed the attached. To some extent this underscores how little weight should be attached to the comments column. It's designed for tzselect and may not work as well with anything that doesn't behave like tzselect.
Paul Eggert via tz <tz@iana.org> writes:
On 2023-01-07 13:51, Clive D.W. Feather wrote:
Should "most areas" be "all other areas"?
Sure, I installed the attached.
That will make the entry pretty much unintelligible in any context where it's not presented right next to Büsingen.
To some extent this underscores how little weight should be attached to the comments column. It's designed for tzselect and may not work as well with anything that doesn't behave like tzselect.
If that's a truly hard policy, then OK, but it sounds a little too tunnel-vision-y from here. I would think that it's important to be sure that any entry presented on its own is understandable. regards, tom lane
On 2023-01-07 15:54, Tom Lane wrote:
I would think that it's important to be sure that any entry presented on its own is understandable.
Unfortunately that's too hard to arrange, as context-free strings would become too long be practical for tzselect to use in its messages. I expect the best we can do is make things work reasonably well for the sort of contexts that 'tzselect' uses, and hope that other programs use similar contexts. (This is not to say that we couldn't improve tzselect to make the contexts clearer.)
On Jan 07 2023, Paul Eggert via tz wrote:
Please select one of the following timezones. 1) Büsingen enclave 2) Germany (most areas)
In the context of Germany, Büsingen is an exclave. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Wikipedia's least esoteric alternative to "exclave'" is "detached part." (Wikipedia's most entertaining alternative is "peculiar.") https://en.m.wikipedia.org/wiki/Enclave_and_exclave#Origin_and_usage @dashdashado On Sat, Jan 7, 2023, 7:19 PM Paul Eggert via tz <tz@iana.org> wrote:
On 2023-01-07 15:12, Andreas Schwab wrote:
In the context of Germany, Büsingen is an exclave.
Good point, thanks. However, "exclave" is so esoteric that I expect it'd be more trouble than it's worth. I installed the attached.
On Sat, 2023-01-07 at 19:25 -0500, Arthur David Olson via tz wrote:
Wikipedia's least esoteric alternative to "exclave'" is "detached part." (Wikipedia's most entertaining alternative is "peculiar.")
https://en.m.wikipedia.org/wiki/Enclave_and_exclave#Origin_and_usage
@dashdashado
On Sat, Jan 7, 2023, 7:19 PM Paul Eggert via tz <tz@iana.org> wrote:
On 2023-01-07 15:12, Andreas Schwab wrote:
In the context of Germany, Büsingen is an exclave.
Good point, thanks. However, "exclave" is so esoteric that I expect it'd be more trouble than it's worth. I installed the attached.
I have been knowing the word and meaning "exclave" for a long time. Having exclave in the comment would easily explain why it had a timezone difference, but this information is not important for selecting the timezone. So I am fine with dropping "exclave". -- Benjamin Drung Debian & Ubuntu Developer
On Sat, 2023-01-07 at 13:30 -0800, Paul Eggert wrote:
On 2023-01-07 01:53, Benjamin Drung via tz wrote:
Thanks. Could you add " (Germany)" to Büsingen? It is too small to be commonly known in Germany.
I looked into how that string is used, came up with what I hope is a better idea, tested it, and fixed another glitch or two that I found.
The idea is that zone1970.tab's comment column should cover only countries that have multiple timezones, so that it needn't worry about summarizing all the other countries (which don't need the summary anyway).
I installed the attached patches to implement this. With it, if you run tzselect and choose Germany, you see:
Please select one of the following timezones. 1) Büsingen enclave 2) Germany (most areas)
which I hope is good enough in the context where you've already picked Germany. It's OK when someone who runs tzselect doesn't know about Büsingen, as they should just shrug and pick the "most areas" line.
Patch 1 implements this change.
Thanks. This improves the timezone selection and I am happy about the result. The updated description of the comments column is clear enough to understand the purpose. The "present if and only if" could be checked by some tool.
Patch 3 improves tzselect so that it takes advantage of the Patch 1 change. This change improves behavior both with older and bleeding-edge tzdata. Older tzselects will still work, though their (already-confusing) messages will be perhaps a bit more confusing in some cases. I hope this tzselect improvement migrates into Ubuntu soon.
tzselect is shipped by the libc-bin binary package which comes from the glibc source package. I do not know and haven't investigated how tzselect migrates to the glibc source package (is this Debian/Ubuntu specific or does glibc upstream include it?). -- Benjamin Drung Debian & Ubuntu Developer
On 2023-01-07 18:01, Benjamin Drung via tz wrote:
The "present if and only if" could be checked by some tool.
"make check" has been doing that since release 96k. However, I just now tested it and found a bug in the check when applied to the zone1970.tab format introduced in 2014f. I fixed the bug by installing the attached proposed patch.
On Jan 7, 2023, at 6:01 PM, Benjamin Drung via tz <tz@iana.org> wrote:
tzselect is shipped by the libc-bin binary package which comes from the glibc source package. I do not know and haven't investigated how tzselect migrates to the glibc source package (is this Debian/Ubuntu specific or does glibc upstream include it?).
Upstream glibc includes it. tzdb releases include: the source time information files; source to zic and zdump, and their man pages; source to a version of the date command, and its man page; Makefile and assorted build scripts, including Awk files; assorted documents; *and* source to versions of C library routines that use the tzdb. This renders it something that doesn't conveniently fit into the package structure of operating systems divided into packages (various Linux distributions, as well as Darwin), as those C library routines generally belong in a "system library (or component thereof)" package. Glibc has its own independent implementation of localtime() etc., using the tzdb, with its own code for reading tzdb files; presumably they put at least some of the rest of the tzdb release, including tzselect, into glibc because the API part is there. Presumably updating glibc with a new tzdb release involves 1) updating libc's tzdb-reading code to support any new tzif features (and fix any bugs that we fixed, if they're also in their code, as well as picking up features they think reasonable) and 2) picking up new versions of the rest of the code and data.
On 2023-01-08 12:46, Guy Harris via tz wrote:
Presumably updating glibc with a new tzdb release involves 1) updating libc's tzdb-reading code to support any new tzif features (and fix any bugs that we fixed, if they're also in their code, as well as picking up features they think reasonable) and 2) picking up new versions of the rest of the code and data.
Nowadays glibc does (1) but only part of (2). Glibc no longer syncs from tzdata (it has a copy of an old version, but just for testing; it's not meant for use). Instead, GNU/Linux distros put tzdata into a separate package, so that data can be updated quickly and independently of the C library. tzcode's executables are also typically put into a separate package, so at least three packages are involved: one for the C library, one for the tzcode executables, and one for tzdata. On Ubuntu these packages are called "libc6", "libc-bin", and "tzdata". Glibc copies of tzcode source files like tzselect.ksh and zic.c are byte-for-byte identical with tzcode. In other words, there isn't a fork like there is currently with NetBSD (something I'd like to see fixed). That being said, the GNU C library's copies of tzcode were last synced from tzdb 2020a, so they're due for a refresh, whenever I or someone else gets around to doing that.
On Sat, 7 Jan 2023, Paul Eggert via tz wrote:
The idea is that zone1970.tab's comment column should cover only countries that have multiple timezones, so that it needn't worry about summarizing all the other countries (which don't need the summary anyway).
Unfortunately, it still puts several countries into one timezone. While selecting Sweden, Norway or Denmark skips the last step, so it doesn't say "Germany" any longer, entering coordinates will: #? 11 Please enter coordinates in ISO 6709 notation. For example, +4042-07403 stands for 40 degrees 42 minutes north, 74 degrees 3 minutes west. +6000+1000 Please select one of the following timezones, echo listed roughly in increasing order of distance from +6000+1000. 1) Germany, Denmark, Norway, Sweden, Svalbard & Jan Mayen - Germany (all other areas) 2) Czech Republic, Slovakia 3) Belgium, Luxembourg, Netherlands 4) Russia - MSK-01 - Kaliningrad 5) Switzerland, Germany, Liechtenstein - Büsingen 6) Estonia 7) Finland, Åland Islands 8) Latvia 9) Britain (UK), Guernsey, Isle of Man, Jersey 10) Poland While it does give the country names on the first line, the "Germany (all other areas)" comment is slightly confusing (personally I find the choice of German time confusing, calling EU or Brussels time would probably be less confusing). (I currently maintain a patch to disambiguate cases where multiple countries are listed for the same timezone for the time selector in my $DAYJOB product; my UI is based on time, as the system is most likely to have a valid UTC time, so the user will first select the current wall-clock time and then a location for that time.) -- \\// Peter - http://www.softwolves.pp.se/
On 2023-01-08 23:19, Peter Krefting via tz wrote:
#? 11 Please enter coordinates in ISO 6709 notation. For example, +4042-07403 stands for 40 degrees 42 minutes north, 74 degrees 3 minutes west. +6000+1000 Please select one of the following timezones, echo listed roughly in increasing order of distance from +6000+1000. 1) Germany, Denmark, Norway, Sweden, Svalbard & Jan Mayen - Germany (all other areas)
Yes, that's pretty bad. Thanks for pointing it out. I installed the attached patches; please give them a try.
my UI is based on time, as the system is most likely to have a valid UTC time, so the user will first select the current wall-clock time and then a location for that time.
Nice idea.
2023-01-10 08:14 skrev Paul Eggert:
Yes, that's pretty bad. Thanks for pointing it out. I installed the attached patches; please give them a try.
Now we're talking! This is the sort of display I could try to adapt into my time selector. Great work! -- \\// Peter - http://www.softwolves.pp.se/
On 2023-01-09 23:14, Paul Eggert wrote:
my UI is based on time, as the system is most likely to have a valid UTC time, so the user will first select the current wall-clock time and then a location for that time.
Nice idea.
As the sincerest form of flattery, I implemented something like that in TZDB's tzselect program by installing the attached proposed patches. This sort of implementation via the shell would have been pretty slow decades ago, but with modern CPUs it should be fast enough for human users. Here's a sample shell interaction using this new feature. Although not as good as a GUI, I hope this helps inspire other uses of this idea. And perhaps if we ever get around to implementing the simplified interface for users who care only about timestamps from now on, tzselect can get even simpler when exploiting this idea. $ tzselect Please identify a location so that time zone rules can be set correctly. Please select a continent, ocean, "coord", "TZ", or "time". 1) Africa 2) Americas 3) Antarctica 4) Arctic Ocean 5) Asia 6) Atlantic Ocean 7) Australia 8) Europe 9) Indian Ocean 10) Pacific Ocean 11) coord - I want to use geographical coordinates. 12) TZ - I want to specify the timezone using the Posix TZ format. 13) time - I know local time already. #? 13 What is the current date and 24-hour time? 1) Mon Jan 16 15:34 14) Tue Jan 17 02:34 27) Tue Jan 17 10:34 2) Mon Jan 16 16:34 15) Tue Jan 17 03:34 28) Tue Jan 17 11:19 3) Mon Jan 16 17:04 16) Tue Jan 17 04:34 29) Tue Jan 17 11:34 4) Mon Jan 16 17:34 17) Tue Jan 17 05:34 30) Tue Jan 17 12:04 5) Mon Jan 16 18:34 18) Tue Jan 17 06:04 31) Tue Jan 17 12:34 6) Mon Jan 16 19:34 19) Tue Jan 17 06:34 32) Tue Jan 17 13:04 7) Mon Jan 16 20:34 20) Tue Jan 17 07:04 33) Tue Jan 17 13:34 8) Mon Jan 16 21:34 21) Tue Jan 17 07:34 34) Tue Jan 17 14:34 9) Mon Jan 16 22:34 22) Tue Jan 17 08:04 35) Tue Jan 17 15:34 10) Mon Jan 16 23:04 23) Tue Jan 17 08:19 36) Tue Jan 17 16:19 11) Mon Jan 16 23:34 24) Tue Jan 17 08:34 37) Tue Jan 17 16:34 12) Tue Jan 17 00:34 25) Tue Jan 17 09:04 13) Tue Jan 17 01:34 26) Tue Jan 17 09:34 #? 1 Please select a country whose clocks agree with yours. 1) Niue 3) US minor outlying islands 2) Samoa (American) #? 1 Based on the following information: Mon Jan 16 15:34 Niue TZ='Pacific/Niue' will be used. Selected time is now: Mon Jan 16 15:34:25 -11 2023. Universal Time is now: Tue Jan 17 02:34:25 UTC 2023. Is the above information OK? 1) Yes 2) No #? 1 You can make this change permanent for yourself by appending the line TZ='Pacific/Niue'; export TZ to the file '.profile' in your home directory; then log out and log in again. Here is that TZ value again, this time on standard output so that you can use the ./tzselect command in shell scripts: Pacific/Niue $
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
On 1/17/23 00:31, Robert Elz wrote:
the more common usage would seem to be when installing a system, where nothing can be assumed about the system's clock at all
My impression is that during installation most systems nowadays get UTC from NTP, and do not ask the user for the current time. By the time these installations ask for a timezone, UTC is already known. It's been many years since an install asked me for the current time. No doubt things work differently on non-networked installations, but increasingly these are done only in specialized environments where installers are assumed to be somewhat expert anyway, so I'm not as worried about them.
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).
Yes, I don't know any way either. Thanks for the suggestion. tzselect already warns to some extent, as it asks you to confirm both local time and UTC. However, tzselect can do better by rewording its earlier questions so that it asks for the relation between local time and UTC, not for the current local time. That way, even if the platform's UTC clock is wrong the questions and answers still make sense. I installed the attached proposed patch to try to do that.
participants (10)
-
Andreas Schwab -
Arthur David Olson -
Benjamin Drung -
Clive D.W. Feather -
Guy Harris -
Paul Eggert -
Peter Krefting -
Philip Paeps -
Robert Elz -
Tom Lane