State of Palestine Time zone - need to update
Dear Sir/Madam, In reference to your recent response at 25 Oct,2020 regarding State of Palestine's request to correct the 'Time Zone Database', we would like to confirm that 'TZ' related to the State of Palestine is as follows: PS State of Palestine Asia/East Jerusalem UTC +2:00 Also, we would like to inform you that the State of Palestine comprises of the West Bank, including East Jerusalem and Gaza, all of which are integral parts of the State of Palestine, thus, as one territorial unit all areas belong to the same time zone. We would like to also emphasize that East Jerusalem is an integral part of the West Bank as stipulated under international law and by numerous international resolutions. Therefore, we urge you to adopt the official name and correct your data base. Best Regards, Heba Hamad 11 Feb,2021
As is the case with many other situations around the world, this listing is based on the de facto situation. The de jure status is wholly irrelevant here. Jacob Pratt On Thu, Feb 11, 2021, 04:50 heba hamad <heba.hamad@mtit.gov.ps> wrote:
Dear Sir/Madam,
In reference to your recent response at 25 Oct,2020 regarding State of Palestine’s request to correct the ‘Time Zone Database’, we would like to confirm that ‘TZ’ related to the State of Palestine is as follows:
*PS State of Palestine Asia/East Jerusalem UTC +2:00*
Also, we would like to inform you that the State of Palestine comprises of the West Bank, including East Jerusalem and Gaza, all of which are integral parts of the State of Palestine, thus, as one territorial unit all areas belong to the same time zone.
We would like to also emphasize that East Jerusalem is an integral part of the West Bank as stipulated under international law and by numerous international resolutions.
Therefore, we urge you to adopt the official name and correct your data base.
Best Regards,
Heba Hamad
11 Feb,2021
I think if you asked people on the ground in Palestine, they would say that it is the government of the State of Palestine that sets the time zones, and that they live in the State of Palestine. On 2021-02-11 06:23, Jacob Pratt wrote:
As is the case with many other situations around the world, this listing is based on the de facto situation. The de jure status is wholly irrelevant here.
Jacob Pratt
On Thu, Feb 11, 2021, 04:50 heba hamad <heba.hamad@mtit.gov.ps <mailto:heba.hamad@mtit.gov.ps>> wrote:
Dear Sir/Madam,
In reference to your recent response at 25 Oct,2020 regarding State of Palestine’s request to correct the ‘Time Zone Database’, we would like to confirm that ‘TZ’ related to the State of Palestine is as follows:
*_PS State of Palestine Asia/East Jerusalem UTC +2:00_*
Also, we would like to inform you that the State of Palestine comprises of the West Bank, including East Jerusalem and Gaza, all of which are integral parts of the State of Palestine, thus, as one territorial unit all areas belong to the same time zone.
We would like to also emphasize that East Jerusalem is an integral part of the West Bank as stipulated under international law and by numerous international resolutions.
Therefore, we urge you to adopt the official name and correct your data base.
Best Regards,
Heba Hamad
11 Feb,2021
On 2021-02-11 02:50, heba hamad wrote:
In reference to your recent response at 25 Oct,2020 regarding State of Palestine’s request to correct the ‘Time Zone Database’, we would like to confirm that ‘TZ’ related to the State of Palestine is as follows:
*_PS State of Palestine Asia/East Jerusalem UTC +2:00_*
Also, we would like to inform you that the State of Palestine comprises of the West Bank, including East Jerusalem and Gaza, all of which are integral parts of the State of Palestine, thus, as one territorial unit all areas belong to the same time zone.
We would like to also emphasize that East Jerusalem is an integral part of the West Bank as stipulated under international law and by numerous international resolutions.
Therefore, we urge you to adopt the official name and correct your data base.
IETF motto: "We reject: kings, presidents, and voting. We believe in: rough consensus and running code." We provide pragmatic, useful information and care only what people's watches and systems are set to over a significant region and over a significant period of time. The territory mentioned is disputed but continues to fall under under the control of Israel which sets the time zones used on the ground. The situation is similar in Crimea and elsewhere in the world. Anyone who wishes may set their systems to use Asia/Gaza, Asia/Hebron, or Asia/Jerusalem depending on the time they want to see. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in binary units and prefixes, physical quantities in SI.]
There seems to be a serious inconsistency between how Palestine is handled, and how Kiev is handled, and how Xinjiang is handled. As I said, people on the ground in Gaza and Kiev and Xinjiang clearly care that their own systems are honoured, and clearly citizens there don't call themselves part of Israel's Palestinian Territories, Russia's colonies, nor China's. The current naming is clearly favouring the occupiers, over the actual users of that data. On 2021-02-11 14:06, Brian Inglis wrote:
On 2021-02-11 02:50, heba hamad wrote:
In reference to your recent response at 25 Oct,2020 regarding State of Palestine’s request to correct the ‘Time Zone Database’, we would like to confirm that ‘TZ’ related to the State of Palestine is as follows:
*_PS State of Palestine Asia/East Jerusalem UTC +2:00_*
Also, we would like to inform you that the State of Palestine comprises of the West Bank, including East Jerusalem and Gaza, all of which are integral parts of the State of Palestine, thus, as one territorial unit all areas belong to the same time zone.
We would like to also emphasize that East Jerusalem is an integral part of the West Bank as stipulated under international law and by numerous international resolutions.
Therefore, we urge you to adopt the official name and correct your data base.
IETF motto: "We reject: kings, presidents, and voting. We believe in: rough consensus and running code."
We provide pragmatic, useful information and care only what people's watches and systems are set to over a significant region and over a significant period of time.
The territory mentioned is disputed but continues to fall under under the control of Israel which sets the time zones used on the ground. The situation is similar in Crimea and elsewhere in the world.
Anyone who wishes may set their systems to use Asia/Gaza, Asia/Hebron, or Asia/Jerusalem depending on the time they want to see.
On 2021-02-11 12:52, David Patte wrote:
On 2021-02-11 14:06, Brian Inglis wrote:
On 2021-02-11 02:50, heba hamad wrote:
In reference to your recent response at 25 Oct,2020 regarding State of Palestine’s request to correct the ‘Time Zone Database’, we would like to confirm that ‘TZ’ related to the State of Palestine is as follows:
*_PS State of Palestine Asia/East Jerusalem UTC +2:00_*
Also, we would like to inform you that the State of Palestine comprises of the West Bank, including East Jerusalem and Gaza, all of which are integral parts of the State of Palestine, thus, as one territorial unit all areas belong to the same time zone.
We would like to also emphasize that East Jerusalem is an integral part of the West Bank as stipulated under international law and by numerous international resolutions.
Therefore, we urge you to adopt the official name and correct your data base.
IETF motto: "We reject: kings, presidents, and voting. We believe in: rough consensus and running code."
We provide pragmatic, useful information and care only what people's watches and systems are set to over a significant region and over a significant period of time.
The territory mentioned is disputed but continues to fall under under the control of Israel which sets the time zones used on the ground. The situation is similar in Crimea and elsewhere in the world.
Anyone who wishes may set their systems to use Asia/Gaza, Asia/Hebron, or Asia/Jerusalem depending on the time they want to see.
There seems to be a serious inconsistency between how Palestine is handled, and how Kiev is handled, and how Xinjiang is handled. Each government gets to say what time should be used when by the residents in the territories they *control*, whether that is Russia, Ukraine, Israel, Palestine, Gaza, or Xinjiang Uyghur Autonomous Region.
As I said, people on the ground in Gaza and Kiev and Xinjiang clearly care that their own systems are honoured, and clearly citizens there don't call themselves part of Israel's Palestinian Territories, Russia's colonies, nor China's. What people's opinions are about what they wish is irrelevant: what matters is what the reality is in the region, and we reflect that, we don't decide that. They might also wish we used the calendar they use, but we don't, and don't care, and won't change, even although the support and capability has been available for decades, and many rules would make more sense expressed in their native calendars.
The current naming is clearly favouring the occupiers, over the actual users of that data. It always favours what is used by those people who reside in the region, whether they have the government they would choose or not. Many of us might also prefer to have different governments, or use different time zones than those in effect where we reside. If you really dislike a time zone or a government, you will have to try to change it, or else move elsewhere, otherwise you will just have to put up with what you have.
The users of the data are the downstream systems using the project, and they are not pushing us to make any of these changes, they deal with their issues internally, and have to put up with the project making random unplanned changes, because of a few emails about spelling in a language not native to them, that would better be automoderated out of notice. The naming is *meant* to be an internal identifier, and I personally hold the opinion that they should never be changed, until association or comprehension is misleading or negligible, as they are irrelevant outside of this project. I see a lot of code in a lot of projects with crappy, insane, or even inverted identifiers, but I don't waste my time complaining about those usages, or submitting mass variable renaming patches. I just hope that the contributors or maintainers will sensibly refactor those usages when sufficient maintenance is required, or confusion has been caused. If downstreams or other sites expose or misuse those identifiers, the complainers should be told to complain about wherever they see them, as they chose to expose or misuse those identifiers. Those downstreams, few of whom likely contribute to this project, rather it is the reverse where this project contributes freely to their business, as is our preference, nor do most acknowledge, nor care about this project, as the information is in the public domain, seem to do a better job of saying *NO* to complainers, who also have no vested interest in this project, do not make any contributions, and do not really care, except about petty political campaigns, to which they have been stirred up by ineffectual politicians, where the best they can do is provoke people to argue about spellings in a language they don't use, nor know much of. Having caved to Ukraine, I would not be surprised to see more campaigns, to press for more politically motivated changes, that useless politicians can point to as accomplishments when nothing else is progressing. That is why I am a verbose advocate of telling complainers to submit patches or PRs for consideration, fork the sources on github, patch the software they use to suit themselves, or *go pound sand*! -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in binary units and prefixes, physical quantities in SI.]
On Thu, Feb 11, 2021 at 3:21 PM Brian Inglis < Brian.Inglis@systematicsw.ab.ca> wrote:
The naming is *meant* to be an internal identifier, and I personally hold the opinion that they should never be changed, until association or comprehension is misleading or negligible, as they are irrelevant outside of this project.
I agree that primary identifiers should almost never be changed, for maximum backwards compatibility. But I've been reading this list for about 3 years, and I don't still don't understand why there is reluctance to add LINK entries. Wouldn't that resolve most of these requests? I think this entry for Kyiv: LINK Europe/Kiev Europe/Kyiv would have prevented about 100 emails on this list. That is why I am a verbose advocate of telling complainers to submit
patches or PRs for consideration, fork the sources on github, patch the software they use to suit themselves, or *go pound sand*!
Is this reasonable? Most people don't know how to submit patches to the TZ. I've been reading this list for several years, and I don't. Many people know how to submit GitHub PRs, but PRs are not accepted on this project. If various timezone libraries (e.g. libc, Java Time, Python pytz, dateutils, JavaScript moment, etc) had easy ways to regenerate their data from custom TZDB files, then maybe this response would make more sense. But the procedure for regenerating the local TZ database is often obscure and underdocumented. And if making a locally patched TZ database was made too easy, I think there would be a proliferation of custom identifiers (e.g. "Asia/East_Jerusalem"). Then time zone identifiers would no longer be interoperable and exchangeable. I don't think that's where we want to go. Brian
On 2/11/21 4:20 PM, Brian Park wrote:
I don't still don't understand why there is reluctance to add LINK entries. Wouldn't that resolve most of these requests?
We'd keep getting requests, though, if word got out that one could plant political flags into tzdb simply by asking. Suppose North Korea started calling Seoul "Kim Il-sung City" on the grounds that it's their city and they can call it what they want? And that is not a fanciful supposition: North Koreans seriously suggested doing exactly that in the 1990s after Kim Il-sung died. At some point we need to say that tzdb is about civil time, not about settling or documenting other political disputes. We might as well say it now rather than later.
I would say that is a poor example. North Korea is recognized worldwide as being a different country than the location of Seoul. But there is an organization that is responsible for making decisions on such issues. I still don't understand why the maintainers of this database seem so hesitant to recognize the UN's (and its branches) main purpose is to be the party that was exactly set up to be the resolver of such issues, and is duly recognized by nearly every nation on earth for that exact purpose. Its not perfect, but that is its job. It clearly seems to me that the maintainers of this database prefer to apply their own anglo-centric and america-centric politics to the data instead of deferring to that responsibility that the party the rest of the world recognizes was setup to reduce such public squabbling. For the remaining billions of people, and millions of software developers in the world, that are not American, the current decision process of this db is is truly insulting and arrogant. On 2021-02-12 05:14, Paul Eggert wrote:
On 2/11/21 4:20 PM, Brian Park wrote:
I don't still don't understand why there is reluctance to add LINK entries. Wouldn't that resolve most of these requests?
We'd keep getting requests, though, if word got out that one could plant political flags into tzdb simply by asking. Suppose North Korea started calling Seoul "Kim Il-sung City" on the grounds that it's their city and they can call it what they want? And that is not a fanciful supposition: North Koreans seriously suggested doing exactly that in the 1990s after Kim Il-sung died.
At some point we need to say that tzdb is about civil time, not about settling or documenting other political disputes. We might as well say it now rather than later.
On 2021-02-12 07:04, David Patte wrote:
On 2021-02-12 05:14, Paul Eggert wrote:
On 2/11/21 4:20 PM, Brian Park wrote:
I don't still don't understand why there is reluctance to add LINK entries. Wouldn't that resolve most of these requests?
We'd keep getting requests, though, if word got out that one could plant political flags into tzdb simply by asking. Suppose North Korea started calling Seoul "Kim Il-sung City" on the grounds that it's their city and they can call it what they want? And that is not a fanciful supposition: North Koreans seriously suggested doing exactly that in the 1990s after Kim Il-sung died.
At some point we need to say that tzdb is about civil time, not about settling or documenting other political disputes. We might as well say it now rather than later.
I would say that is a poor example. North Korea is recognized worldwide as being a different country than the location of Seoul.
But there is an organization that is responsible for making decisions on such issues.
I still don't understand why the maintainers of this database seem so hesitant to recognize the UN's (and its branches) main purpose is to be the party that was exactly set up to be the resolver of such issues, and is duly recognized by nearly every nation on earth for that exact purpose. Its not perfect, but that is its job.
It clearly seems to me that the maintainers of this database prefer to apply their own anglo-centric and america-centric politics to the data instead of deferring to that responsibility that the party the rest of the world recognizes was setup to reduce such public squabbling.
The UN provides a reason and forum for public squabbling by bureaucrats and politicians with that as their assigned role. The UN Secretariat says yes to demands from and tries to please every one of its about 200 members, even when that might interfere with other members' sovereignty, or is against various UN principles, as whether those principles are adhered to in any specific case or country are decided by UN committees, with political agendas, allies, and foes, so it is luckily or unfortunately pretty ineffective in a lot of what some countries try to accomplish using it. I suspect that trade representatives can object to everything down to LOCODEs. For example, Gaza appears to be the only IL/PS tz location with a UN LOCODE: there appears to be nothing for Hebron or Jerusalem, although they may exist under latinized local Arabic or Hebrew names, or that of a commercial centre, industrial park, or nearby transport hub, to avoid any objections e.g. https://service.unece.org/trade/locode/ps.htm
For the remaining billions of people, and millions of software developers in the world, that are not American, the current decision process of this db is is truly insulting and arrogant. The project is for time zone data maintenance, which is unfortunately decided by bureaucrats and politicians, sometimes for political reasons, and unfortunately political issues sometimes get dragged in by outsiders. Politics is all about the arrogance of thinking you know better than all others how they should live their lives, and insulting all others who objects to those views, and object to paying for those holding and espousing those views in an insulting manner.
If any of the millions of software developers objected, they could fork this project, and set up in competition; same for almost every open source software product. Most of the contributors to open source for some reason seem to be English speaking and northern Europeans and North Americans, possibly because of their relative openness, freedom, and wealth, with many others spread across the world who presumably share the same abilities and situations. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in binary units and prefixes, physical quantities in SI.]
UN is never meant to be what you claim. The main function of UN is to maintain peace and security of the world, and in many cases it mean appeasing the vision of some country over others, for example the unrecognition of Taiwan. Data in tz database have already been depoliticalized by not including any reference to countries in identifier names. It would be politicalizing if you try to apply the standard of UN on to it, which must not be mistaken the United Nation is in itself a political organization.
I think everybody could be satisfied by a small semantic redefinition of the meaning of Link records. The current practice seems to be: 1. Link records in the main files indicate that a given zone's data are also used for an area in another country. Example in file europe Link Europe/Belgrade Europe/Ljubljana # Slovenia Link Europe/Belgrade Europe/Podgorica # Montenegro Link Europe/Belgrade Europe/Sarajevo # Bosnia and Herzegovina Link Europe/Belgrade Europe/Skopje # North Macedonia Link Europe/Belgrade Europe/Zagreb # Croatia Example in file Africa Link Africa/Abidjan Africa/Bamako # Mali Link Africa/Abidjan Africa/Banjul # Gambia Link Africa/Abidjan Africa/Conakry # Guinea Link Africa/Abidjan Africa/Dakar # Senegal Link Africa/Abidjan Africa/Freetown # Sierra Leone Link Africa/Abidjan Africa/Lome # Togo Link Africa/Abidjan Africa/Nouakchott # Mauritania Link Africa/Abidjan Africa/Ouagadougou # Burkina Faso Link Africa/Abidjan Atlantic/St_Helena # St Helena 2. Link records in file backward # This file provides links between current names for timezones # and their old names. Many names changed in late 1993. ... Link Asia/Kolkata Asia/Calcutta ... If the meaning of Link records in the main files were expanded to also indicate alternative zone names, then an entry in file europe # alternative zone name Europe/Kyiv Link Europe/Kiev Europe/Kyiv would satisfy the Ukrainian requests. Such a link results automatically in the creation of a zoneinfo file Europe/Kyiv which is identical to Europe/Kiev On 12.02.21 11:14, Paul Eggert wrote:
On 2/11/21 4:20 PM, Brian Park wrote:
I don't still don't understand why there is reluctance to add LINK entries. Wouldn't that resolve most of these requests?
We'd keep getting requests, though, if word got out that one could plant political flags into tzdb simply by asking. Suppose North Korea started calling Seoul "Kim Il-sung City" on the grounds that it's their city and they can call it what they want? And that is not a fanciful supposition: North Koreans seriously suggested doing exactly that in the 1990s after Kim Il-sung died.
At some point we need to say that tzdb is about civil time, not about settling or documenting other political disputes. We might as well say it now rather than later.
Alois Treindl said:
If the meaning of Link records in the main files were expanded to also indicate alternative zone names, then an entry in file europe
But *which* alternative names? Can I request Europe/Cambridge? Europe/Swavesey? Europe/Benbecula? As Paul wrote:
I don't still don't understand why there is reluctance to add LINK entries. Wouldn't that resolve most of these requests?
We'd keep getting requests,
-- 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 Fri, 12 Feb 2021, Clive D.W. Feather wrote:
Alois Treindl said:
If the meaning of Link records in the main files were expanded to also indicate alternative zone names, then an entry in file europe
But *which* alternative names? Can I request Europe/Cambridge? Europe/Swavesey? Europe/Benbecula?
As Paul wrote:
I don't still don't understand why there is reluctance to add LINK entries. Wouldn't that resolve most of these requests?
We'd keep getting requests,
This is the whole point of my previous suggestion to conditionally include a local file which the consumer owns and maintains. +--------------------+--------------------------+-----------------------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | paul@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoyette@netbsd.org | +--------------------+--------------------------+-----------------------+
* Paul Goyette:
This is the whole point of my previous suggestion to conditionally include a local file which the consumer owns and maintains.
We need cross-distribution consistency (across container boundaries, for instance), so this locally defined alias approach doesn't quite work for us. We would still have to coordinate, and that would have to be here, or on some etzdata-style fork. Thanks, Florian -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
On 12.02.21 15:55, Clive D.W. Feather wrote:
Alois Treindl said:
If the meaning of Link records in the main files were expanded to also indicate alternative zone names, then an entry in file europe But *which* alternative names? Can I request Europe/Cambridge? Europe/Swavesey? Europe/Benbecula?
No, you cannot. The theory.html files describes quite clearly the rules for which towns qualify as zone names. My suggestion refers primarily to relaxed spelling options for these towns. The Palestinan request contradicts the rules in the theory file. tzdb does not aim to represent capitals for zone names, but the most important population center. Because Hebron is the most populous town in Palestine, it is correctly used as zone name.
On 12/02/2021 16:04, Alois Treindl wrote:
The Palestinan request contradicts the rules in the theory file. tzdb does not aim to represent capitals for zone names, but the most important population center.
Because Hebron is the most populous town in Palestine, it is correctly used as zone name.
Hebron isn't the most populous town (that would be East Jerusalem, I think), but it is the most populous governorate. -- -=( Ian Abbott <abbotti@mev.co.uk> || MEV Ltd. is a company )=- -=( registered in England & Wales. Regd. number: 02862268. )=- -=( Regd. addr.: S11 & 12 Building 67, Europa Business Park, )=- -=( Bird Hall Lane, STOCKPORT, SK3 0XA, UK. || www.mev.co.uk )=-
That is actually correct, I checked the Palestinian Central Bereau of Statistics (https://www.pcbs.gov.ps/site/lang__en/803/default.aspx) and found the following 2021 projected mid-year population: - Jerusalem (J1, or East Jerusalem): 304,444 - Hebron (Al Khalil): 221,136 - Gaza: 645,576 Hanna. On Fri, Feb 12, 2021 at 4:17 PM Ian Abbott <abbotti@mev.co.uk> wrote:
On 12/02/2021 16:04, Alois Treindl wrote:
The Palestinan request contradicts the rules in the theory file. tzdb does not aim to represent capitals for zone names, but the most important population center.
Because Hebron is the most populous town in Palestine, it is correctly used as zone name.
Hebron isn't the most populous town (that would be East Jerusalem, I think), but it is the most populous governorate.
-- -=( Ian Abbott <abbotti@mev.co.uk> || MEV Ltd. is a company )=- -=( registered in England & Wales. Regd. number: 02862268. )=- -=( Regd. addr.: S11 & 12 Building 67, Europa Business Park, )=- -=( Bird Hall Lane, STOCKPORT, SK3 0XA, UK. || www.mev.co.uk )=-
Just wondering if it might be possible to have a "conditional include" somewhere (backwards file?). In NetBSD our make(1) recognizes the ``.cinclude <file>'' directive to "include <file> if it exists; if the named file does not exist, just ignore the directive. Is there some other portable mechanism to include-<file>-if-present ? This would allow consumers (whether end-users or downstream projects) to maintain their own local extra-links file that would be included, without polluting (and increasing the maintenance costs of the mainline distribution. +--------------------+--------------------------+-----------------------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | paul@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoyette@netbsd.org | +--------------------+--------------------------+-----------------------+
On 2021-02-12, at 07:32:50, Alois Treindl wrote:
I think everybody could be satisfied by a small semantic redefinition of the meaning of Link records.
The current practice seems to be:
1. Link records in the main files indicate that a given zone's data are also used for an area in another country.
I notice, FWIW, that the MacOS distribution (at Mojave) contains no symlinks; the files are entirely replicated. This needlessly expands the DB by about 30% (MacOS nicely supports symlinks) and actually removes information. The casual browser can not tell at a glance that files are duplicated. -- gil
[Subject line retitled from "[tz] "official" zone name alternatives via Link records'.] On 2/12/21 11:31 AM, Paul Gilmartin via tz wrote:
the MacOS distribution (at Mojave) contains no symlinks; the files are entirely replicated.
Yes, unfortunately this sort of problem seems to be relatively common. Fedora and Solaris use hard links: $ ls -li /usr/share/zoneinfo/America/Los_Angeles /usr/share/zoneinfo/US/Pacific 2111636 -rw-r--r--. 2 root root 2836 Jan 25 19:02 /usr/share/zoneinfo/America/Los_Angeles 2111636 -rw-r--r--. 2 root root 2836 Jan 25 19:02 /usr/share/zoneinfo/US/Pacific whereas Ubuntu (and I assume Debian) use less-efficient symbolic links: $ ls -li /usr/share/zoneinfo/America/Los_Angeles /usr/share/zoneinfo/US/Pacific 1182409 -rw-r--r-- 1 root root 2836 Jan 27 11:53 /usr/share/zoneinfo/America/Los_Angeles 1206418 lrwxrwxrwx 1 root root 22 Jan 27 11:53 /usr/share/zoneinfo/US/Pacific -> ../America/Los_Angeles and macOS uses copies, although I don't know whether these are true copies (which would be even less efficient than symlinks), or are merely APFS copy-on-write clones (not so bad). The hard-link approach is zic's original approach, and zic still uses hard links unless the filesystem does not support hard links (or in the rare case where -l or -p is used and the destination exists and is already a symlink). On filesystems that support neither hard links nor symlinks, zic currently falls back by coping via 'read' and 'write'. zic could try ioctl with FICLONE (Linux) or clonefile (macOS) if available, before falling back on 'read' and 'write'. I don't know whether it'd be worth the hassle to do that, though. Partly it depends on why macOS has copies; if the copies are not made by zic, there's not much point to changing zic.
On Feb 12, 2021, at 12:49 PM, Paul Eggert <eggert@cs.ucla.edu> wrote:
On filesystems that support neither hard links nor symlinks,
A category into which neither HFS+ nor APFS falls; they both support both hard links and symlinks. (I think HFS+'s implementation of hard links is *internally* a bit unusual, but they have the full semantics of POSIX hard links.) The same applies, as far as I know, to all the main Linux local file systems. So I don't know why Ubuntu (and possibly Debian) use symlinks, or why macOS is using copies, unless they're both trying to support VFAT or something such as that.
It looks like Catalina (10.15.7) uses hard links: $ ls -li /usr/share/zoneinfo.default/US/Pacific /usr/share/zoneinfo.default/America/Los_Angeles 1152921500311900283 -rw-r--r-- 3 root wheel 2819 Nov 9 2019 /usr/share/zoneinfo.default/America/Los_Angeles 1152921500311900283 -rw-r--r-- 3 root wheel 2819 Nov 9 2019 /usr/share/zoneinfo.default/US/Pacific On Fri, 12 Feb 2021 at 15:49, Paul Eggert <eggert@cs.ucla.edu> wrote:
[Subject line retitled from "[tz] "official" zone name alternatives via Link records'.]
On 2/12/21 11:31 AM, Paul Gilmartin via tz wrote:
the MacOS distribution (at Mojave) contains no symlinks; the files are entirely replicated.
Yes, unfortunately this sort of problem seems to be relatively common. Fedora and Solaris use hard links:
$ ls -li /usr/share/zoneinfo/America/Los_Angeles /usr/share/zoneinfo/US/Pacific 2111636 -rw-r--r--. 2 root root 2836 Jan 25 19:02 /usr/share/zoneinfo/America/Los_Angeles 2111636 -rw-r--r--. 2 root root 2836 Jan 25 19:02 /usr/share/zoneinfo/US/Pacific
whereas Ubuntu (and I assume Debian) use less-efficient symbolic links:
$ ls -li /usr/share/zoneinfo/America/Los_Angeles /usr/share/zoneinfo/US/Pacific 1182409 -rw-r--r-- 1 root root 2836 Jan 27 11:53 /usr/share/zoneinfo/America/Los_Angeles 1206418 lrwxrwxrwx 1 root root 22 Jan 27 11:53 /usr/share/zoneinfo/US/Pacific -> ../America/Los_Angeles
and macOS uses copies, although I don't know whether these are true copies (which would be even less efficient than symlinks), or are merely APFS copy-on-write clones (not so bad).
The hard-link approach is zic's original approach, and zic still uses hard links unless the filesystem does not support hard links (or in the rare case where -l or -p is used and the destination exists and is already a symlink).
On filesystems that support neither hard links nor symlinks, zic currently falls back by coping via 'read' and 'write'. zic could try ioctl with FICLONE (Linux) or clonefile (macOS) if available, before falling back on 'read' and 'write'. I don't know whether it'd be worth the hassle to do that, though. Partly it depends on why macOS has copies; if the copies are not made by zic, there's not much point to changing zic.
On Feb 12, 2021, at 1:01 PM, Emily Crandall Fleischman <emilycf@mit.edu> wrote:
It looks like Catalina (10.15.7) uses hard links:
$ ls -li /usr/share/zoneinfo.default/US/Pacific /usr/share/zoneinfo.default/America/Los_Angeles 1152921500311900283 -rw-r--r-- 3 root wheel 2819 Nov 9 2019 /usr/share/zoneinfo.default/America/Los_Angeles 1152921500311900283 -rw-r--r-- 3 root wheel 2819 Nov 9 2019 /usr/share/zoneinfo.default/US/Pacific
Depends on where you look: $ ls -li /usr/share/zoneinfo.default/US/Pacific /usr/share/zoneinfo.default/America/Los_Angeles 1152921500311900257 -rw-r--r-- 3 root wheel 2819 Oct 9 2019 /usr/share/zoneinfo.default/America/Los_Angeles 1152921500311900257 -rw-r--r-- 3 root wheel 2819 Oct 9 2019 /usr/share/zoneinfo.default/US/Pacific $ ls -li /usr/share/zoneinfo/America/Los_Angeles /usr/share/zoneinfo/US/Pacific 56302834 -rw-r--r-- 1 root wheel 2819 Oct 21 20:45 /usr/share/zoneinfo/America/Los_Angeles 56302650 -rw-r--r-- 1 root wheel 2819 Oct 21 20:45 /usr/share/zoneinfo/US/Pacific Deborah? Any idea what's going on here? For what it's worth, /usr/share/zoneinfo.default and /usr/share/zoneinfo are on different file systems: $ df /usr/share/zoneinfo.default Filesystem 512-blocks Used Available Capacity iused ifree %iused Mounted on /dev/disk1s1 15633066472 21990936 11080851032 1% 488348 78164844012 0% / $ df /usr/share/zoneinfo Filesystem 512-blocks Used Available Capacity iused ifree %iused Mounted on /dev/disk1s2 15633066472 4497237704 11080851032 29% 11077044 78154255316 0% /System/Volumes/Data
/usr/share/zoneinfo is a soft link: % ls -l /usr/share/zoneinfo lrwxr-xr-x 1 root wheel 25 Jan 1 2020 /usr/share/zoneinfo -> /var/db/timezone/zoneinfo /var/db/timezone/zoneinfo is also a soft link: % ls -l /var/db/timezone/zoneinfo lrwxr-xr-x 1 root wheel 38 Feb 8 21:00 /var/db/timezone/zoneinfo -> /var/db/timezone/tz/2021a.1.0/zoneinfo The reason for two soft links is that /usr/share is (currently) on a read-only volume, so /usr/share/zoneinfo must point at a fixed location. /var/db/timezone/tz is where over-the-air time zone updates are stored. If there is no OTA time zone update installed, /var/db/timezone/zoneinfo points at /usr/share/zoneinfo.default. The OTA time zone update distribution machinery does not currently support the preservation of hard links, so when /usr/share/zoneinfo points at an OTA update, there are no hard links. This is a known issue. All of this is subject to change, of course. Thanks, Deborah
On Feb 12, 2021, at 1:13 PM, Guy Harris <gharris@sonic.net> wrote:
On Feb 12, 2021, at 1:01 PM, Emily Crandall Fleischman <emilycf@mit.edu> wrote:
It looks like Catalina (10.15.7) uses hard links:
$ ls -li /usr/share/zoneinfo.default/US/Pacific /usr/share/zoneinfo.default/America/Los_Angeles 1152921500311900283 -rw-r--r-- 3 root wheel 2819 Nov 9 2019 /usr/share/zoneinfo.default/America/Los_Angeles 1152921500311900283 -rw-r--r-- 3 root wheel 2819 Nov 9 2019 /usr/share/zoneinfo.default/US/Pacific
Depends on where you look:
$ ls -li /usr/share/zoneinfo.default/US/Pacific /usr/share/zoneinfo.default/America/Los_Angeles 1152921500311900257 -rw-r--r-- 3 root wheel 2819 Oct 9 2019 /usr/share/zoneinfo.default/America/Los_Angeles 1152921500311900257 -rw-r--r-- 3 root wheel 2819 Oct 9 2019 /usr/share/zoneinfo.default/US/Pacific $ ls -li /usr/share/zoneinfo/America/Los_Angeles /usr/share/zoneinfo/US/Pacific 56302834 -rw-r--r-- 1 root wheel 2819 Oct 21 20:45 /usr/share/zoneinfo/America/Los_Angeles 56302650 -rw-r--r-- 1 root wheel 2819 Oct 21 20:45 /usr/share/zoneinfo/US/Pacific
Deborah? Any idea what's going on here? For what it's worth, /usr/share/zoneinfo.default and /usr/share/zoneinfo are on different file systems:
$ df /usr/share/zoneinfo.default Filesystem 512-blocks Used Available Capacity iused ifree %iused Mounted on /dev/disk1s1 15633066472 21990936 11080851032 1% 488348 78164844012 0% / $ df /usr/share/zoneinfo Filesystem 512-blocks Used Available Capacity iused ifree %iused Mounted on /dev/disk1s2 15633066472 4497237704 11080851032 29% 11077044 78154255316 0% /System/Volumes/Data
On Feb 12, 2021, at 4:56 PM, Deborah Goldsmith <goldsmit@apple.com> wrote:
/var/db/timezone/zoneinfo is also a soft link:
% ls -l /var/db/timezone/zoneinfo lrwxr-xr-x 1 root wheel 38 Feb 8 21:00 /var/db/timezone/zoneinfo -> /var/db/timezone/tz/2021a.1.0/zoneinfo
So how many /var/db/timezone/tz/{version} tzdbs are kept around? $ ls /var/db/timezone/tz 2020d.1.0 2020f.1.0 2021a.1.0 And why are older versions kept around?
Deborah Goldsmith wrote:
The OTA time zone update distribution machinery does not currently support the preservation of hard links, so when /usr/share/zoneinfo points at an OTA update, there are no hard links.
Guy Harris replied:
So how many /var/db/timezone/tz/{version} tzdbs are kept around? $ ls /var/db/timezone/tz 2020d.1.0 2020f.1.0 2021a.1.0
What's fascinating to me is that they are there at all. I'm a foot-dragging Luddite who rarely accepts any of the upgrades that vendors push at me -- and yet now that I look, I've got those same three fresh tz trees sitting there on my Mac, too, one from as recently as three weeks ago. Did everybody else know this? Apologies for making a big deal out of it if everybody else already knew this. Evidently OTA is chugging away there quietly in the background, upgrading tzdata completely transparently. (I'm not complaining, I'm just surprised.) Anybody know if there's a connection between OTA's tzdata distribution mechanism, and TZDIST? I'm guessing not. (But now I'm wondering if the reason I haven't heard much about TZDIST lately is that OTA has rendered it obsolete, or something.)
scs@eskimo.com (Steve Summit) writes:
What's fascinating to me is that they are there at all. I'm a foot-dragging Luddite who rarely accepts any of the upgrades that vendors push at me -- and yet now that I look, I've got those same three fresh tz trees sitting there on my Mac, too, one from as recently as three weeks ago.
Did everybody else know this? Apologies for making a big deal out of it if everybody else already knew this. Evidently OTA is chugging away there quietly in the background, upgrading tzdata completely transparently.
If you look in System Preferences -> Software Update -> Advanced, you'll find a checkbox "Install system data files and security updates", which is generally on even if you don't have automatic software update enabled. I believe that's what authorizes auto-installation of tzdata updates, along with lists of trusted website root certificates, CRLs, antivirus patterns, and the like.
Anybody know if there's a connection between OTA's tzdata distribution mechanism, and TZDIST? I'm guessing not. (But now I'm wondering if the reason I haven't heard much about TZDIST lately is that OTA has rendered it obsolete, or something.)
I'm pretty certain Deborah is just referring to Apple's proprietary software update channel. regards, tom lane
OTA is just my shorthand for “over the air,” by which I mean not included as part of an OS software update. It’s not an official name or anything. Sorry if that wasn’t clear. Here is the support page on this mechanism: https://support.apple.com/en-us/HT206986 And here is the support page on background updates: https://support.apple.com/en-us/HT207005 Deborah
On Feb 13, 2021, at 8:55 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
scs@eskimo.com (Steve Summit) writes:
What's fascinating to me is that they are there at all. I'm a foot-dragging Luddite who rarely accepts any of the upgrades that vendors push at me -- and yet now that I look, I've got those same three fresh tz trees sitting there on my Mac, too, one from as recently as three weeks ago.
Did everybody else know this? Apologies for making a big deal out of it if everybody else already knew this. Evidently OTA is chugging away there quietly in the background, upgrading tzdata completely transparently.
If you look in System Preferences -> Software Update -> Advanced, you'll find a checkbox "Install system data files and security updates", which is generally on even if you don't have automatic software update enabled. I believe that's what authorizes auto-installation of tzdata updates, along with lists of trusted website root certificates, CRLs, antivirus patterns, and the like.
Anybody know if there's a connection between OTA's tzdata distribution mechanism, and TZDIST? I'm guessing not. (But now I'm wondering if the reason I haven't heard much about TZDIST lately is that OTA has rendered it obsolete, or something.)
I'm pretty certain Deborah is just referring to Apple's proprietary software update channel.
regards, tom lane
On Feb 13, 2021, at 6:24 PM, Deborah Goldsmith via tz <tz@iana.org> wrote:
OTA is just my shorthand for “over the air,” by which I mean not included as part of an OS software update. It’s not an official name or anything. Sorry if that wasn’t clear.
Here is the support page on this mechanism:
https://support.apple.com/en-us/HT206986
And here is the support page on background updates:
The latter page doesn't list tzdb files under "System data files". Is that because the people in charge figured that explaining the tzdb to end users would be more trouble than it's worth (although they do mention "Updated definitions for SSL certificate types", which is equally nerdy)?
Old versions should be removed at some point. Thanks, Deborah
On Feb 13, 2021, at 1:11 AM, Guy Harris <gharris@sonic.net> wrote:
On Feb 12, 2021, at 4:56 PM, Deborah Goldsmith <goldsmit@apple.com> wrote:
/var/db/timezone/zoneinfo is also a soft link:
% ls -l /var/db/timezone/zoneinfo lrwxr-xr-x 1 root wheel 38 Feb 8 21:00 /var/db/timezone/zoneinfo -> /var/db/timezone/tz/2021a.1.0/zoneinfo
So how many /var/db/timezone/tz/{version} tzdbs are kept around?
$ ls /var/db/timezone/tz 2020d.1.0 2020f.1.0 2021a.1.0
And why are older versions kept around?
Paul Eggert <eggert@cs.ucla.edu> writes:
whereas Ubuntu (and I assume Debian) use less-efficient symbolic links:
$ ls -li /usr/share/zoneinfo/America/Los_Angeles /usr/share/zoneinfo/US/Pacific 1182409 -rw-r--r-- 1 root root 2836 Jan 27 11:53 /usr/share/zoneinfo/America/Los_Angeles 1206418 lrwxrwxrwx 1 root root 22 Jan 27 11:53 /usr/share/zoneinfo/US/Pacific -> ../America/Los_Angeles
The decision in Debian (which I assume Ubuntu is just importing) appears to have been made in 2011: * Remove hardlinks to comply with the policy, by replacing identical files with symlinks. It also reduces the package size by 38% and the installed size by 35%. I'm not sure what's going on with the package size and installed size, although it's possible that the proper tar extensions weren't used at the time to record the files as hard links and they turned into copies in the tar file and thus on unpack. The first part of the changelog entry appears to be a (common) misunderstanding of Debian Policy, which prohibits hard links in source packages and as conffiles but not for regular files in binary packages. That said, personally I prefer symlinks to hardlinks as a matter of style. Hard links on a UNIX system have a very opaque UI with standard tools. It's apparent (although not exactly obvious; I always forget to check the link count number) that the contents are shared with another file, but not which other file or files, something that symlinks make obvious. The efficiency difference seems unlikely to matter. I admit that my bias against hard links is probably influenced from having spent years working with a file system that didn't support hard links across directories. -- Russ Allbery (eagle@eyrie.org) <https://www.eyrie.org/~eagle/>
On 12.02.21 20:31, Paul Gilmartin via tz wrote:
I notice, FWIW, that the MacOS distribution (at Mojave) contains no symlinks; the files are entirely replicated. This needlessly expands the DB by about 30% (MacOS nicely supports symlinks) and actually removes information. The casual browser can not tell at a glance that files are duplicated.
Nobody should worry about these 30%, I think, these days. A lot more of space is wasted, everywhere. On my Mac (Catalina) I find at least three full copies of tzdb ls -l /var/db/timezone/tz drwxr-xr-x 5 root wheel 160 27 Okt 03:33 2020d.1.0 drwxr-xr-x 5 root wheel 160 31 Jan 04:26 2020f.1.0 drwxr-xr-x 5 root wheel 160 2 Feb 04:27 2021a.1.0
On Feb 12, 2021, at 05:14, Paul Eggert <eggert@cs.ucla.edu> wrote:
At some point we need to say that tzdb is about civil time, not about settling or documenting other political disputes. We might as well say it now rather than later.
If this is the policy (and I think it is the correct one), then we need to become utterly consistent about its implementation. There are really only two consistent possibilities: TZ identifiers are arbitrary and immutable. Or they’re not. If the first is true, then they should *never* change. Ever. For any reason. (*Additional* ids can of course be introduced, but that’s a different situation, already well covered in the theory document). Of course, this means that the ostensible “meaning” of the various IDs will slowly drift away from correspondence with political realities over time. Oh well. They’re arbitrary. Deal with it. To say that ‘TZ identifiers are arbitrary tags’, but then go ahead and change *some* of them in response to various forms of special pleading does nothing but open the project up to charges of being arbitrary and capricious. No wonder the politicians are confused about the process. It’s a confusion that we ourselves have fostered. Until and unless we consistently apply this policy, these arguments about names are going to be endless. TZ identifiers are arbitrary and immutable. Or they’re not. Which is it going to be? Cheers! |---------------------------------------------------------------------| | Frederick F. Gleason, Jr. | Chief Developer | | | Paravel Systems | |---------------------------------------------------------------------| | "On two occasions I have been asked [by members of Parliament], | | `Pray, Mr. Babbage, if you put into the machine wrong figures, will | | the right answers come out?' I am not able rightly to apprehend the | | kind of confusion of ideas that could provoke such a question." | | | | -- Charles Babbage | |---------------------------------------------------------------------|
Date: Fri, 12 Feb 2021 10:33:11 -0500 From: Fred Gleason <fredg@paravelsystems.com> Message-ID: <8782E03A-C352-44C0-8041-E6B16D28B869@paravelsystems.com> | If the first is true, then they should *never* change. Ever. For any | reason. I think, possibly aside from some very early changes (long long ago) that has always been true. Aside from any pedagogical reason, it is required to maintain backwards compatibility. | *Additional* ids can of course be introduced, That's all we ever do - both when a zone splits (what was one zone becomes two or more, because the rules which used to apply throughout the area covered by the zone will no longer be consistent), and second because for one reason or another there's to be a change of name. The "change" is always just the addition of a new ID, the old one remains. While we ignore the political nonsense most of the time, as the IDs are (kind of) arbitrary, they're also used to simplify maintenance. When someone tells us the the clocks in some part of the world are to alter on some specific (hopefully reasonably far future) date, it is much easier to be sure that the correct zone is being altered if it has a name that corresponds. If it weren't for that we might as well call the zones tzz1 tzz2 tzz3 ... kre
在 2021年2月11日週四 17:50，heba hamad <heba.hamad@mtit.gov.ps> 寫道：
Dear Sir/Madam,
In reference to your recent response at 25 Oct,2020 regarding State of Palestine’s request to correct the ‘Time Zone Database’, we would like to confirm that ‘TZ’ related to the State of Palestine is as follows:
*PS State of Palestine Asia/East Jerusalem UTC +2:00*
Note that, TZ database use most populous city in an area to determine zone name, not administrative center.
Also, we would like to inform you that the State of Palestine comprises of the West Bank, including East Jerusalem and Gaza, all of which are integral parts of the State of Palestine, thus, as one territorial unit all areas belong to the same time zone.
Please note that, TZ database assign different zones to area ever have different time since year 1970. As there were time since then that the two places have different zones, there are now multiple zones in the country, similar to situation in countries like United States, Australia and Mexico
participants (22)
-
Alois Treindl -
Brian Inglis -
Brian Park -
Clive D.W. Feather -
David Patte -
Deborah Goldsmith -
Emily Crandall Fleischman -
Florian Weimer -
Fred Gleason -
Guy Harris -
Hanna Kreitem -
heba hamad -
Ian Abbott -
Jacob Pratt -
Paul Eggert -
Paul Gilmartin -
Paul Goyette -
Phake Nick -
Robert Elz -
Russ Allbery -
scs＠eskimo.com -
Tom Lane