Re: [tz] winter & Summer time in the State Of Palestine
the text is correct and matches with the cabinet decision that is attached previously ,so kindly ignore the illustration we will correct the illustration in the announcement and send the link again but to keep time we confirm that the text is correct we hope the TZ release will be issued as soon as possible في الأحد, سبتمبر 04, 2022 17:53 EDT, Paul Eggert <eggert@cs.ucla.edu> كتب: On 9/4/22 06:00, Michael H Deckers wrote:
The illustration on that page makes it clear that the Arabic text is probably meant to say winter time starts with the value 2 am on Saturday 2022-10-29 rather than the switch to winter time occurs when summer time would have assumed the value 2 am on Saturday 2022-10-29 as it was wrongly interpreted in the proposed changes to Rule Palestine.
Ouch. My guess is just the opposite. That is, my guess is that the illustration[1] (attached) in [2] is wrong, and I guess that the text is correct. That is, I think the illustration should show the clock moving backward from 2am to 1am, not from 3am to 2am. Heba Hamad, can you please confirm which is correct here? The illustration or the text? The text matches the document you already sent us. Thanks. [1]: https://mtit.pna.ps/Content/imgs/news/-8585393378987544401IMG-20220903-WA000... [2]: https://mtit.pna.ps/Site/New/1453
On 9/4/22 23:48, heba.hamad@mtit.gov.ps wrote:
the text is correct and matches with the cabinet decision that is attached previously ,so kindly ignore the illustration we will correct the illustration
Thanks, I see the illustration is fixed now, and I installed the attached. We should see a new release soon,though not today as it's a holiday in the US.
Dear Sir, Yes the illustration was be corrected ,and here the link to enable other members make sure https://www.mtit.pna.ps/Site/New/1453 BR, في الاثنين, سبتمبر 05, 2022 12:21 EDT, Paul Eggert <eggert@cs.ucla.edu> كتب: On 9/4/22 23:48, heba.hamad@mtit.gov.ps wrote:
the text is correct and matches with the cabinet decision that is attached previously ,so kindly ignore the illustration we will correct the illustration
Thanks, I see the illustration is fixed now, and I installed the attached. We should see a new release soon,though not today as it's a holiday in the US.
On Mon, Sep 05, 2022 at 11:21:06 -0500, Paul Eggert via tz wrote:
attached. We should see a new release soon,though not today as it's a holiday in the US.
Presumably you are already aware that 2022d has not appeared yet :) ... but since the above message implies that the release would likely be happening in the week of Sept 6, I thought enough time had elapsed that it was worth sending in this note, to suggest that might want to you post a status update to the list to clarify the current situation... Nathan ---------------------------------------------------------------------------- Nathan Stratton Treadway - nathanst@ontko.com - Mid-Atlantic region Ray Ontko & Co. - Software consulting services - http://www.ontko.com/ GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt ID: 1023D/ECFB6239 Key fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239
On 9/18/22 12:38, Nathan Stratton Treadway via tz wrote:
but since the above message implies that the release would likely be happening in the week of Sept 6
"Soon" is relative. :-) We still plan to issue a new release soon, but as usual with tzdb there is no set schedule.
Hello, I am new to the list. I submitted a bug through Canonical regarding the time zone for Ecuador and they told me that it would need to be reported upstream in this list. I am sure if must have been reported before, but I would like to confirm. Ecuador has currently two time zones, one for the mainland, and another for the Galapagos Islands. The city that is listed for the mainland is Guayaquil, with no mention of the capital Quito. Guayaquil is the second most populous city in Ecuador, but why it is the only city listed is odd. It is akin to choosing Marseilles as the only city for France instead of Paris. Is there any chance of having Quito added?
Date: Mon, 19 Sep 2022 11:21:37 +0100 From: David via tz <tz@iana.org> Message-ID: <39316283-6bc5-cd01-f7d0-a1c61f44bad5@pov.es> | Ecuador has currently two time zones, one for the mainland, and | another for the Galapagos Islands. Yes. | The city that is listed for the mainland is Guayaquil, with no mention | of the capital Quito. Being the capital is irrelevant. We also do not have Washington, Ottawa, Beijing, or New Delhi as zone names for zones in the USA, Canada, China, or India, but rather New York (which isn't even the capital of its state), Toronto, Shanghai, and Kolkata instead. | Guayaquil is the second most populous city in Ecuador, The population data I have seen suggests it is the most populous, at about 2 million people, with Quito second, at about 1.4 million. Certainly deciding what exactly is to be counted as being the city for these purposes isn't always simple, and relative populations do alter over time, but once a city is chosen as the name for a zone, being consistent means that we rarely change. (Eg: it may be that the population of Beijing is now greater than, or at least, similar to, that of Shanghai - but it wasn't when the name was chosen). | but why it is the only city listed is odd. There is only one (as we understand, and you confirmed above) mainland timezone. The timezone and its data is what is important, not its name. One zone needs only one name. This project has (long ago) decided to pick the name of the most populous city/town to use the timezone in question as the name of the zone, and by that rule, and the population data available, Guayaquil is it. | It is akin to choosing Marseilles as the only city for France instead of | Paris. Paris is more populous than Marseilles. As is London than Birmingham. Capitals are often (but not always) the biggest city, so it happens that the names of capitals are chosen as timezone names quite frequently, but it has nothing at all do do with them being the capital. | Is there any chance of having Quito added? Not a lot I suspect. But if you have some particular desire to have that happen locally (if you ever really normally ever see the zone name) you can simply make a link (or copy) of the zone data file (the TZif file). kre
Thank you for your reply. It is more or less what I was expecting, but I need to correct you on the population data you have seen. Quito, both the city and metro areas are bigger than Guayaquil. Albeit not by much. My argument and whole point was that from an end-user point of view, when choosing a city to select a time zone for Ecuador Guayaquil will not be the first choice. And I am pretty sure that in a huge proportion of cases it won't be the second either. I am embarrassed to admit, that despite being familiar with Ecuador, I ended up choosing another country in my settings. It took an OS upgrade for this to bother me enough to look into it deeper and find about Guayaquil. I can't extrapolate my own experience to all users, but I would be surprised to have been the only one. On 19/09/2022 13:19, Robert Elz wrote:
Date: Mon, 19 Sep 2022 11:21:37 +0100 From: David via tz <tz@iana.org> Message-ID: <39316283-6bc5-cd01-f7d0-a1c61f44bad5@pov.es>
| Ecuador has currently two time zones, one for the mainland, and | another for the Galapagos Islands.
Yes.
| The city that is listed for the mainland is Guayaquil, with no mention | of the capital Quito.
Being the capital is irrelevant. We also do not have Washington, Ottawa, Beijing, or New Delhi as zone names for zones in the USA, Canada, China, or India, but rather New York (which isn't even the capital of its state), Toronto, Shanghai, and Kolkata instead.
| Guayaquil is the second most populous city in Ecuador,
The population data I have seen suggests it is the most populous, at about 2 million people, with Quito second, at about 1.4 million.
Certainly deciding what exactly is to be counted as being the city for these purposes isn't always simple, and relative populations do alter over time, but once a city is chosen as the name for a zone, being consistent means that we rarely change.
(Eg: it may be that the population of Beijing is now greater than, or at least, similar to, that of Shanghai - but it wasn't when the name was chosen).
| but why it is the only city listed is odd.
There is only one (as we understand, and you confirmed above) mainland timezone. The timezone and its data is what is important, not its name. One zone needs only one name.
This project has (long ago) decided to pick the name of the most populous city/town to use the timezone in question as the name of the zone, and by that rule, and the population data available, Guayaquil is it.
| It is akin to choosing Marseilles as the only city for France instead of | Paris.
Paris is more populous than Marseilles. As is London than Birmingham. Capitals are often (but not always) the biggest city, so it happens that the names of capitals are chosen as timezone names quite frequently, but it has nothing at all do do with them being the capital.
| Is there any chance of having Quito added?
Not a lot I suspect. But if you have some particular desire to have that happen locally (if you ever really normally ever see the zone name) you can simply make a link (or copy) of the zone data file (the TZif file).
kre
David wrote in separate messages:
My argument and whole point was that from an end-user point of view, when choosing a city to select a time zone for Ecuador Guayaquil will not be the first choice. And I am pretty sure that in a huge proportion of cases it won't be the second either.
Other operating systems allow the selection of Quito and I found it odd, that's all.
A bad user experience is to hand the user a list of raw tz identifiers and expect her to choose the right one. A much better experience is to hand the user a list of cities, possibly arranged by country and subdivisions, and ask her to pick one of those whose standard time matches the user's. The website timeanddate.com tries to detect the user's location (a step which not all systems or applications can perform), guesses the correct time zone, and allows the user to pick another nearby city. In highly populated urban areas, it may offer a choice of several adjacent cities. For me, it guessed Denver but gave me a quick choice of Lakewood, Aurora, or Centennial (all of which share a border with Denver, in the middle of the state and of the time zone) as well as three other nearby cities. The GeoNames project provides a list of almost 5 million populated places, including almost 200,000 cities and towns with populations over 500, all with associated tz identifiers. Lists like these could be used in a UI to select a time zone. (There was a thread two months ago about GeoNames assigning the wrong tz identifier to locations in Ontario, Canada, but that problem appears to be confined to the OpenStreetMap implementation that uses GeoNames data, rather than to GeoNames itself. Two cities mentioned in particular in that thread, Barrie and Picton, are coded correctly in GeoNames.) https://www.timeanddate.com/ https://www.geonames.org/ -- Doug Ewell, CC, ALB | Lakewood, CO, US | ewellic.org
2022년 9월 19일 (월) 오후 7:22, David via tz <tz@iana.org>님이 작성:
The city that is listed for the mainland is Guayaquil, with no mention of the capital Quito. Guayaquil is the second most populous city in Ecuador, but why it is the only city listed is odd.
It is akin to choosing Marseilles as the only city for France instead of Paris.
Is there any chance of having Quito added?
https://data.iana.org/time-zones/theory.html explains how tz database chooses timezone identifier. It is "Use the most populous among locations in a region", so it is not necessarily the capital. If Marseilles had more population than Paris, Marseilles would have been chosen. In fact, it is Asia/Shanghai, not Asia/Beijing, for the same reason. Now, Guayaquil seems to be the second most populous city in Ecuador, but I think it was more populous than Quito in the past, and even now their population is similar. Since another rule is "Among locations with similar populations, pick the best-known location", maybe it was better to choose Quito, since I think it is better known because it is the capital. Alas, yet another rule is "Do not change established names if they only marginally violate the above guidelines. For example, do not change the existing name Europe/Rome to Europe/Milan merely because Milan's population has grown to be somewhat greater than Rome's." I think it is exactly the case here. For better or worse, America/Guayaquil is now established, so it won't be changed to America/Quito, even if Quito is now more populous than Guayaquil. So no, there is no chance of having Quito added. -- Seo Sanghyeon
Thank you for your reply, Sanghyeon.
Alas, yet another rule is "Do not change established names if they only marginally violate the above guidelines. For example, do not change the existing name Europe/Rome to Europe/Milan merely because Milan's population has grown to be somewhat greater than Rome's." I think it is exactly the case here.
I understand your point but it is puzzling to think how outside this list Guayaquil has a bigger relationship to Ecuador than Quito for the majority of users. I asked several Ecuadorian friends if this is common when selecting a time zone because I found it odd, and they were as puzzled as me. I know that someone else raised this on a really old version of Red Hat, and I brought it up because it is an issue on Ubuntu. In both operating systems they feed from this list upstream and they won't make changes. I am pretty sure that this is something that affects a huge variety of OS that use this list. It wasn't and it isn't my intention to convince you to make any changes, just merely making you aware of the impact it is having on users. Other operating systems allow the selection of Quito and I found it odd, that's all. Thanks again for taking the time to reply. On 19/09/2022 13:36, Seo Sanghyeon wrote:
2022년 9월 19일 (월) 오후 7:22, David via tz <tz@iana.org>님이 작성:
The city that is listed for the mainland is Guayaquil, with no mention of the capital Quito. Guayaquil is the second most populous city in Ecuador, but why it is the only city listed is odd.
It is akin to choosing Marseilles as the only city for France instead of Paris.
Is there any chance of having Quito added?
https://data.iana.org/time-zones/theory.html explains how tz database chooses timezone identifier. It is "Use the most populous among locations in a region", so it is not necessarily the capital. If Marseilles had more population than Paris, Marseilles would have been chosen. In fact, it is Asia/Shanghai, not Asia/Beijing, for the same reason.
Now, Guayaquil seems to be the second most populous city in Ecuador, but I think it was more populous than Quito in the past, and even now their population is similar. Since another rule is "Among locations with similar populations, pick the best-known location", maybe it was better to choose Quito, since I think it is better known because it is the capital.
Alas, yet another rule is "Do not change established names if they only marginally violate the above guidelines. For example, do not change the existing name Europe/Rome to Europe/Milan merely because Milan's population has grown to be somewhat greater than Rome's." I think it is exactly the case here. For better or worse, America/Guayaquil is now established, so it won't be changed to America/Quito, even if Quito is now more populous than Guayaquil.
So no, there is no chance of having Quito added.
On 2022-09-19 14:10:14+0100, David via tz <tz@iana.org> wrote:
Thank you for your reply, Sanghyeon.
Alas, yet another rule is "Do not change established names if they only marginally violate the above guidelines. For example, do not change the existing name Europe/Rome to Europe/Milan merely because Milan's population has grown to be somewhat greater than Rome's." I think it is exactly the case here.
I understand your point but it is puzzling to think how outside this list Guayaquil has a bigger relationship to Ecuador than Quito for the majority of users. I asked several Ecuadorian friends if this is common when selecting a time zone because I found it odd, and they were as puzzled as me.
Yes, it's odd, but at least it have some connection to Ecuador. Until you see that Laotian, Cambodian (and to a degree, Northern Vietnamese) users need to set their timezone to Asia/Bangkok, which is a city in an unrelated country.
I know that someone else raised this on a really old version of Red Hat, and I brought it up because it is an issue on Ubuntu. In both operating systems they feed from this list upstream and they won't make changes. I am pretty sure that this is something that affects a huge variety of OS that use this list.
It wasn't and it isn't my intention to convince you to make any changes, just merely making you aware of the impact it is having on users. Other operating systems allow the selection of Quito and I found it odd, that's all.
Thanks again for taking the time to reply.
On 19/09/2022 13:36, Seo Sanghyeon wrote:
2022년 9월 19일 (월) 오후 7:22, David via tz <tz@iana.org>님이 작성:
The city that is listed for the mainland is Guayaquil, with no mention of the capital Quito. Guayaquil is the second most populous city in Ecuador, but why it is the only city listed is odd.
It is akin to choosing Marseilles as the only city for France instead of Paris.
Is there any chance of having Quito added?
https://data.iana.org/time-zones/theory.html explains how tz database chooses timezone identifier. It is "Use the most populous among locations in a region", so it is not necessarily the capital. If Marseilles had more population than Paris, Marseilles would have been chosen. In fact, it is Asia/Shanghai, not Asia/Beijing, for the same reason.
Now, Guayaquil seems to be the second most populous city in Ecuador, but I think it was more populous than Quito in the past, and even now their population is similar. Since another rule is "Among locations with similar populations, pick the best-known location", maybe it was better to choose Quito, since I think it is better known because it is the capital.
Alas, yet another rule is "Do not change established names if they only marginally violate the above guidelines. For example, do not change the existing name Europe/Rome to Europe/Milan merely because Milan's population has grown to be somewhat greater than Rome's." I think it is exactly the case here. For better or worse, America/Guayaquil is now established, so it won't be changed to America/Quito, even if Quito is now more populous than Guayaquil.
So no, there is no chance of having Quito added.
-- Danh
Đoàn Trần Công Danh wrote in <Yyhs1xtElMI5WM6u@danh.dev>: |On 2022-09-19 14:10:14+0100, David via tz <tz@iana.org> wrote: ... |Yes, it's odd, but at least it have some connection to Ecuador. |Until you see that Laotian, Cambodian (and to a degree, Northern |Vietnamese) users need to set their timezone to Asia/Bangkok, |which is a city in an unrelated country. You can use Asia/Ho_Chi_Minh, /Saigon, /Phnom_Penh, /Vientiane. It is found by tzselect(8) if you use the undocumented "-t zone" option: $ tzselect -t zone Please identify a location so that time zone rules can be set correctly. Please select a continent, ocean, "coord", or "TZ". 1) Africa 5) Asia 9) Indian Ocean 2) Americas 6) Atlantic Ocean 10) Pacific Ocean 3) Antarctica 7) Australia 11) coord - I want to use geographical coordinates. 4) Arctic Ocean 8) Europe 12) TZ - I want to specify the timezone using the Posix TZ format. #? 5 Please select a country whose clocks agree with yours. 1) Afghanistan 8) Cambodia 15) Indonesia 22) Korea (North) 29) Malaysia 36) Philippines 43) Taiwan 50) Yemen 2) Armenia 9) China 16) Iran 23) Korea (South) 30) Mongolia 37) Qatar 44) Tajikistan 3) Azerbaijan 10) Cyprus 17) Iraq 24) Kuwait 31) Myanmar (Burma) 38) Russia 45) Thailand 4) Bahrain 11) East Timor 18) Israel 25) Kyrgyzstan 32) Nepal 39) Saudi Arabia 46) Turkmenistan 5) Bangladesh 12) Georgia 19) Japan 26) Laos 33) Oman 40) Singapore 47) United Arab Emirates 6) Bhutan 13) Hong Kong 20) Jordan 27) Lebanon 34) Pakistan 41) Sri Lanka 48) Uzbekistan 7) Brunei 14) India 21) Kazakhstan 28) Macau 35) Palestine 42) Syria 49) Vietnam #? 8 The following information has been given: Cambodia Therefore TZ='Asia/Phnom_Penh' will be used. Selected time is now: Mon Sep 19 21:19:23 +07 2022. Universal Time is now: Mon Sep 19 14:19:23 UTC 2022. Is the above information OK? 1) Yes 2) No #? 1 You can make this change permanent for yourself by appending the line TZ='Asia/Phnom_Penh'; 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 /usr/bin/tzselect command in shell scripts: Asia/Phnom_Penh I strongly recommend to document that option as well as making !zone1970 the default, _or_ being more verbose and show both saying something along the lines "shares timezone information with" or what. I would be willing to write an according patch. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
On 2022-09-19 16:21:25+0200, Steffen Nurpmeso <steffen@sdaoden.eu> wrote:
Đoàn Trần Công Danh wrote in |On 2022-09-19 14:10:14+0100, David via tz <tz@iana.org> wrote: ... |Yes, it's odd, but at least it have some connection to Ecuador. |Until you see that Laotian, Cambodian (and to a degree, Northern |Vietnamese) users need to set their timezone to Asia/Bangkok, |which is a city in an unrelated country.
You can use Asia/Ho_Chi_Minh, /Saigon, /Phnom_Penh, /Vientiane.
Yes, I know about /Ho_Chi_Minh and /Saigon (it's my correct timezone, since I live in the Southern part of Vietnam), since Saigon is distinct from Bangkok (until 1976).
It is found by tzselect(8) if you use the undocumented "-t zone" option:
Anyway, thanks for "-t zone", it works for Vientiane and Phnom_Penh, however, it doesn't work for Hanoi (which is used for North Vietnam). Hanoi has different timezone history from Saigon until 1976, but Hanoi has same history with Bangkok from 1970. Not sure if I built tzutils incorrectly. But, - "tzselect" w/o any options will choose Asia/Bangkok for North Vietnam and Asia/Ho_Chi_Minh for South Vietnam, so North Vietnam will have incorrect historical timezone pre-1970, which is not tzdb's concern - "tzselect -t zone" will choose Asia/Ho_Chi_Minh for the whole Vietnam, which has incorrect timezone history for North Vietnam from 1954 until 1976
I strongly recommend to document that option as well as making !zone1970 the default, _or_ being more verbose and show both saying something along the lines "shares timezone information with" or what.
I would be willing to write an according patch.
--steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
-- Danh
On 2022-09-19 22:21:58+0700, Đoàn Trần Công Danh <congdanhqx@gmail.com> wrote:
On 2022-09-19 16:21:25+0200, Steffen Nurpmeso <steffen@sdaoden.eu> wrote:
Đoàn Trần Công Danh wrote in |On 2022-09-19 14:10:14+0100, David via tz <tz@iana.org> wrote: ... |Yes, it's odd, but at least it have some connection to Ecuador. |Until you see that Laotian, Cambodian (and to a degree, Northern |Vietnamese) users need to set their timezone to Asia/Bangkok, |which is a city in an unrelated country.
You can use Asia/Ho_Chi_Minh, /Saigon, /Phnom_Penh, /Vientiane.
Yes, I know about /Ho_Chi_Minh and /Saigon (it's my correct timezone, since I live in the Southern part of Vietnam), since Saigon is distinct from Bangkok (until 1976).
It is found by tzselect(8) if you use the undocumented "-t zone" option:
Anyway, thanks for "-t zone", it works for Vientiane and Phnom_Penh, however, it doesn't work for Hanoi (which is used for North Vietnam). Hanoi has different timezone history from Saigon until 1976, but Hanoi has same history with Bangkok from 1970.
Not sure if I built tzutils incorrectly. But,
- "tzselect" w/o any options will choose Asia/Bangkok for North Vietnam and Asia/Ho_Chi_Minh for South Vietnam, so North Vietnam will have incorrect historical timezone pre-1970, which is not tzdb's concern - "tzselect -t zone" will choose Asia/Ho_Chi_Minh for the whole Vietnam, which has incorrect timezone history for North Vietnam from 1954 until 1976
I figured out, in order to have correct timezone for North Vietnam with "tzselect -t zone", we need to apply this patch: From: =?UTF-8?q?=C4=90o=C3=A0n=20Tr=E1=BA=A7n=20C=C3=B4ng=20Danh?= <congdanhqx@gmail.com> Date: Mon, 19 Sep 2022 22:38:05 +0700 Subject: [PATCH] =?UTF-8?q?Add=20link=20for=C2=A0North=20Vietnam=20timezon?= =?UTF-8?q?e?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- asia | 1 + zone.tab | 3 ++- 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/asia b/asia index def9b204..a5b00bc4 100644 --- a/asia +++ b/asia @@ -3833,6 +3833,7 @@ Zone Asia/Dushanbe 4:35:12 - LMT 1924 May 2 Zone Asia/Bangkok 6:42:04 - LMT 1880 6:42:04 - BMT 1920 Apr # Bangkok Mean Time 7:00 - +07 +Link Asia/Bangkok Asia/Hanoi # North Vietnam Link Asia/Bangkok Asia/Phnom_Penh # Cambodia Link Asia/Bangkok Asia/Vientiane # Laos Link Asia/Bangkok Indian/Christmas diff --git a/zone.tab b/zone.tab index 1f73ddaf..62cb1069 100644 --- a/zone.tab +++ b/zone.tab @@ -443,7 +443,8 @@ VC +1309-06114 America/St_Vincent VE +1030-06656 America/Caracas VG +1827-06437 America/Tortola VI +1821-06456 America/St_Thomas -VN +1045+10640 Asia/Ho_Chi_Minh +VN +2101+10551 Asia/Hanoi Vietnam (north) +VN +1045+10640 Asia/Ho_Chi_Minh Vietnam (south) VU -1740+16825 Pacific/Efate WF -1318-17610 Pacific/Wallis WS -1350-17144 Pacific/Apia -- 2.38.0.rc0
Đoàn Trần Công Danh wrote in <YyiQVelD+iBHN0V8@danh.dev>: |On 2022-09-19 22:21:58+0700, Đoàn Trần Công Danh <congdanhqx@gmail.com> \ |wrote: |> On 2022-09-19 16:21:25+0200, Steffen Nurpmeso <steffen@sdaoden.eu> wrote: |>> Đoàn Trần Công Danh wrote in |>>|On 2022-09-19 14:10:14+0100, David via tz <tz@iana.org> wrote: ... |> Anyway, thanks for "-t zone", it works for Vientiane and Phnom_Penh, |> however, it doesn't work for Hanoi (which is used for North Vietnam). Indeed, here, too. |> Hanoi has different timezone history from Saigon until 1976, but Hanoi |> has same history with Bangkok from 1970. |> |> Not sure if I built tzutils incorrectly. But, |> |> - "tzselect" w/o any options will choose Asia/Bangkok for |> North Vietnam and Asia/Ho_Chi_Minh for South Vietnam, |> so North Vietnam will have incorrect historical timezone pre-1970, |> which is not tzdb's concern |> - "tzselect -t zone" will choose Asia/Ho_Chi_Minh for the whole |> Vietnam, which has incorrect timezone history for North Vietnam |> from 1954 until 1976 | |I figured out, in order to have correct timezone for North Vietnam |with "tzselect -t zone", we need to apply this patch: ... |+++ b/asia ... |+Link Asia/Bangkok Asia/Hanoi # North Vietnam ... |+++ b/zone.tab ... |-VN +1045+10640 Asia/Ho_Chi_Minh |+VN +2101+10551 Asia/Hanoi Vietnam (north) |+VN +1045+10640 Asia/Ho_Chi_Minh Vietnam (south) Surely a bug to be fixed, then! --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
On 9/19/22 07:21, Steffen Nurpmeso via tz wrote:
I strongly recommend to document that option as well as making !zone1970 the default,_or_ being more verbose and show both saying something along the lines "shares timezone information with" or what.
Currently by default, a tzselect user who chooses Vietnam is given two choices, and can pick either zone appropriate for Vietnam since 1970. Unfortunately tzselect will have glitches if an installer uses non-default installation options such as PACKRATDATA but fixing that would take more work than I expect any of us can spare. I haven't documented tzselect's -t option, since it can be glitchy. But if it's documented as being glitchy/experimental/whatever I suppose that would be OK. Any such documentation should be in both the man page and the --help output. I suspect that the complexity of making tzselect be more verbose (to let users choose -t interactively?) would cost users more than it would benefit; after all, tzselect is already pretty complicated (which is my fault of course). But perhaps I'm wrong and someone could implement something nicely.
Paul Eggert wrote in <eb3720c9-0e13-2233-9127-b236b5fdc441@cs.ucla.edu>: |On 9/19/22 07:21, Steffen Nurpmeso via tz wrote: |> I strongly recommend to document that option as well as making |> !zone1970 the default,_or_ being more verbose and show both |> saying something along the lines "shares timezone information |> with" or what. | |Currently by default, a tzselect user who chooses Vietnam is given two |choices, and can pick either zone appropriate for Vietnam since 1970. I see. Indochina is a word i would be careful with myself, but i am sure they all know. |Unfortunately tzselect will have glitches if an installer uses |non-default installation options such as PACKRATDATA but fixing that |would take more work than I expect any of us can spare. | |I haven't documented tzselect's -t option, since it can be glitchy. But |if it's documented as being glitchy/experimental/whatever I suppose that |would be OK. Any such documentation should be in both the man page and |the --help output. I could give this a try. |I suspect that the complexity of making tzselect be more verbose (to let |users choose -t interactively?) would cost users more than it would |benefit; after all, tzselect is already pretty complicated (which is my |fault of course). But perhaps I'm wrong and someone could implement |something nicely. I always learn, and i like learning; if i read <"$f" || { i would never have tried on my own, maybe "<X :", but not without. And the main loop has a tremendous compound-list-1, and a very short compount-list-2. So hard to believe an outsider without real insight can make an acceptable improvement here without hm work. I think the change likely should be as local as possible, maybe around "Get list of timezones in the country." ... So i tried and have a hacky thing that shows what i mean "a little bit"; if we try Asia->Laos with -t zone and without, it shows "the other zonetype" context. But it surely can be improved. Regarding data cuts: isn't it enough to document it as it is done in the patch 0002? Otherwise more context data would have to be placed all around, so that the shell script could say something along the lines "warning, pre-1970 clock times mismatch chosen TZ identifier", that is, when i choose Asia/Vientiane via -t zone (as with the 1970-01-01 cut-off those times are _indeed_ Asia/Bangkok)? --End of <eb3720c9-0e13-2233-9127-b236b5fdc441@cs.ucla.edu> --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
P.S.: I have seen in git that tzselect.8 has a real manual now! Thank you. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Thanks for taking a look at it. The first patch is OK now that we've worked around nawk's bugs, so I installed it (albeit with a different URL). The other two patches have problems, though. They assume that zone1970.tab and zone.tab are the only two possibilities, but a primary reason for -t option is to let users choose other possibilities of their own design. So the second patch needs to be more generic, and not say that there are just two *.tab files; it also needs to say that the -t option is experimental. I suppose it also needs to document the current *.tab file format. And the third patch goes in the wrong direction, as it hardwires the assumption that 'zone1970.tab' and 'zone.tab' are the only two choices and it outputs something cryptic and unactionable to boot. If we're going to change tzselect in this area perhaps it would be better for tzselect to act just as now, but if the user says "no" at the end then give the user an option of trying again with the other *.tab files.
Paul Eggert wrote in <4ca13b77-e1d9-ff01-ebc1-4d8241789a94@cs.ucla.edu>: |Thanks for taking a look at it. The first patch is OK now that we've |worked around nawk's bugs, so I installed it (albeit with a different |URL). The other two patches have problems, though. They assume that |zone1970.tab and zone.tab are the only two possibilities, but a primary |reason for -t option is to let users choose other possibilities of their |own design. It is in sofar an improvement as any user gets an insight on what is, actually, going on. (Without reading the IANA TZ DB file theory.html.) Yes, it reflects my personal preference from including backzone always, but then again The default zone1970 partitions the world into timezones whose clocks all agree about timestamps that occur after 1970-01-01 00:00:00 UTC, so for ( example asking for the location Laos in the area Asia will answer Asia/Bangkok, since this timezone correctly represents the clocks of Laos ) since 1970-01-01. If ZONETYPE is zone, a country based answer will be given, in this case Asia/Vientiane. TZ DB build-time decisions decide whether timezones share pre-1970 clock data or not: if not the above ZONETYPE zone answer is an alias for the timezone Asia/Bangkok. Pre-1970 clock data is often not reliable. reflects the situation quite good i think. Text in parenthesis is too lengthy. To me plain: any user who actually is about to use the shell-level tzselect(8) for TZ selection purposes instead of some graphical interface that, much more or less, hides the political TZ ID problems that make for the most traffic. She runs into the political TZ ID problems. Wants to see Asia/Vientiane. Should know that pre-1970 data likely is _not_ Asia/Vientiane. Eh. Imho "let users choose ... of their own design" is a bit too nitpicking, since the script enforces data at a specific location, or invocations like AWK=nawk TZDIR=/usr/share/zoneinfo bash tzselect.ksh so that is very sophisticated.. is it? |So the second patch needs to be more generic, and not say that there are |just two *.tab files; it also needs to say that the -t option is Adding "ZONETYPE can be any other additionally installed timezone description" would meet these requirements of yours? |experimental. I suppose it also needs to document the current *.tab file |format. These sounds a bit biased to me. But zone.tab and zone1970.tab are serious data collections, yet one reflects merged zones since 1970, the other not. Not that many other possibilities are thinkable, except automatically generated ones that reflect 1:1 the installed variant, which may be an alias to either, but also something with a different clock cut-off. The latter was beyond my intent. |And the third patch goes in the wrong direction, as it hardwires the |assumption that 'zone1970.tab' and 'zone.tab' are the only two choices |and it outputs something cryptic and unactionable to boot. If we're Yes it was a hack. I have to admit i stopped because (a) it was late and (b) my gut feeling told me that you will say something like this regardless of what the outcome is, so putting more than 1.5 hours into this i refrained from doing. But the hack already shows the intent i had in mind, at least with the given "Laos" example, you go with the one zone and get a hint on what the other variant would have shown. It could be improved. |going to change tzselect in this area perhaps it would be better for |tzselect to act just as now, but if the user says "no" at the end then |give the user an option of trying again with the other *.tab files. By re-execing $0 with "the other" -t variant. But only as an additional option to Yes and No. --End of <4ca13b77-e1d9-ff01-ebc1-4d8241789a94@cs.ucla.edu> --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Date: Mon, 19 Sep 2022 14:10:14 +0100 From: David via tz <tz@iana.org> Message-ID: <6078f506-c3ef-29d7-7f57-56dc499bce6c@pov.es> | Other operating systems allow the selection of Quito That is an entirely different question, and one which is OS specific. How users get to select a timezone (either the local one, or some other one for determining the time remotely) is not part of this project. We collect the time zone data, and make it available (doing which requires that it have a label). The various OS makers decide how (using whatever facilities they have available) provide the mechanism for zone selection. Some might show a map, and have you zoom, and then click on somehere, (that requires some kind of graphical display always be available), others might have a list of cities, others countries (and then for countries with multiple zones, a way to select which) - none of that affects the zones that exist, so is none of our business. If you send a message to your OS maintainers along the lines of "Why is there no zone for Quito?" then they're quite right to direct you here (sometimes, a new zone really is required, because the location in question doesn't share the same time history (at least since 1970) as we have believed it does). On the other hand if you ask the OS maintainers "Why can't I select Quito to get the timezone for mainland Ecuador?" and they point you in this direction, then we will simply send you back again, with a message for them that that question is none of our business, and it is for them to answer. kre
participants (9)
-
David -
Doug Ewell -
heba.hamad＠mtit.gov.ps -
Nathan Stratton Treadway -
Paul Eggert -
Robert Elz -
Seo Sanghyeon -
Steffen Nurpmeso -
Đoàn Trần Công Danh