On 2020-06-28 15:22, Alois Treindl wrote:
On 28.06.20 23:12, Paul Eggert wrote:
On 6/28/20 7:42 AM, Alois Treindl wrote:
The public geonames.org database assigns the zone Asia/Ho_Chi_Minh for all location in country VN (Vietnam). This indicates that the comment above is not followed.
That's a problem with the geonames.org database, and I suggest reporting the bug to them. The bug should be reported regardless of whether we change tzdb since geonames.org should work with what we have now as well as with what we might have in the future. You can point them at the zone1970.tab file to help explain the situation.
A little background here. We don't have the resources to create entries for every location in this part of southeast Asia, with different transition times for when locations changed hands between North and South Vietnam during the 1970-1975 conflict. So we approximate by using Ho Chi Minh as the representative for clocks in south Vietnam, and Bangkok as the representative for clocks in Thailand, Cambodia, Laos and north Vietnam. We have links from Asia/Bangkok to Asia/Phnom_Penh and Asia/Vientiane for backward-compatibility purposes only, as the names Asia/Phnom_Penh and Asia/Vientiane would not exist according to today's guidelines. There's no need for a backward-compatibility link for Asia/Hanoi since that name never existed in tzdb. These are all technical reasons, not political ones.
I don't agree. I think the capital of North Vietnam, Asia/Hanoi should be present in the main file, and used. Geonames.org will and should not use zones which exist only in backzone and will not be compiled by default into binary TZ distributions.> They will and should not use the capital of another country, Bangkok, for parts of Vietnam.> In my opinion the case is clear: Hanoi belongs into main file, to cover the 1970-1975 period correctly.
Searching for Vietnam time, I see sites stating that Vietnam follows Indochina Time, so this view does not appear too controversial in the region. I agree from the design point of view that countries should have their own independent time zones, as what they do is so unpredictable, and should not be allowed to affect any other country, so allowing a little judicious duplication would be in order, where there is no political commonality but only geographical proximity or coincidence in decision making. Perhaps the needs of historical communities diverge from those served by the tzdb project over the issue of differences before 1970. You could take the experimental github repo, which has history from 1984, or the tar releases from 1993, and cherry pick which patches to choose to apply, as Oracle does to improve backward compatibility for its major DB product and Java. There is absolutely nothing stopping you from creating and distributing your own patches to tzdata sources, additional source files of rules, zones, and links, or scripts to patch, build, copy, or link files to meet your historical community's needs. -- 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 IEC units and prefixes, physical quantities in SI.]