1981/2 Singapore+Malaysia switch from GMT+0730 to GMT+0800
This press release was discovered, and brought up in another forum by Geoff Clare. It conflicts with the data in the Asia/Singapore and Asia/Kuala-Lumpur zones. https://corporate.nas.gov.sg/media/collections-and-research/time-zone-adjust... That puts the change as being from 23:29:59 Dec 31, 1981 -> 00:00:00 Jan 1, 1982 whereas tzdata (going back to quite ancient versions) has the transition 23:59:59 Dec 31, 1981 -> 00:30:00 Jan 1, 1982 The version from the web page makes more sense to me (as in that is how I would have done that transition) but that does not mean that it is necessarily correct. Nothing there shows a copy of the actual gazette notification by the President (of Singapore in that case, but I think we can safely assume that it was done the same as in Malaysia) which would be the actual specification, but that 2015 press release says it happened as described that it would happen in the 1981 press release which is included there. The "asia" file just says of this transition: 7:30 - +0730 1982 Jan 1 8:00 - +08 which is correct in a sense for either version of when the transition occurred, and perhaps raises a general question of when a step forward takes place at the boundary between two days, does it more often delete the last part of the previous day or the first part of the next? I can find nothing in my tz list archives that says anything at all about this transition - the earliest message with any specific content about Singapore I could see was a Jan 2004 message from Mok Ly Yng (forwarded to the list by ado@), but that's really about earlier transitions - this one was already in the data (just with SGT instead of +0730 and +08). There's also a long Sept 2014 discussion about a zdump bug that this particular transition, as defined by zic, revealed, and a shorter discussion about the SGT removal in Sept 2018 - but that's all I managed to find about Singapore. While not about the Singapore/Malaysia zones themselves, even older data that appears on the list (ie: looking at diffs patches, and updated zone files) shows that in 1996 this transition was believed to have happened in May 1982 (which seems to be from Shanks). That altered in Dec 2003, in a change described as: * Fix several Malaysia and Singapore entries before 1983. Among other things, they enjoyed 20-minute DST from 1933 to 1936, and we have more-accurate dates for WWII transitions. (Thanks to Mok Ly Yng for this info.) which notably does not mention the change moving from May 1982 -> 1 Jan 1982 but that change was made in that version. Nothing appears to have happened since. I suspect it would be correct to change the first of those lines to be 7:30 - +0730 23:30 1981 Dec 30 but I am no authority on that. kre
Date: Wed, 23 Nov 2022 06:39:17 +0700 From: Robert Elz via tz <tz@iana.org> Message-ID: <25577.1669160357@jacaranda.noi.kre.to> | I suspect it would be correct to change the first of those lines | to be | | 7:30 - +0730 23:30 1981 Dec 30 And of course, it would not be - but make that Dec 31 instead and perhaps... Ugh! kre
On 2022-11-22 15:39, Robert Elz via tz wrote:
That puts the change as being from 23:29:59 Dec 31, 1981 -> 00:00:00 Jan 1, 1982
Thanks for catching that mistake. I see that I transcribed Mok Ly Yng's 2003 web page incorrectly; it says the transition occurred at 4 o'clock (16:00) UTC, which agrees with your 23:30 local time. I installed the attached proposed patch. I found confirmation of this correction on page 1 of the Straits Times, 31 December 1981, in an article headlined "Tonight's revelry will end half-hour earlier".
Unless I missed something, that patch only altered Asia/Singapore. I'd be truly astounded if the same was not also required for Asia/Kuala_Lumpur. Here: https://www.therakyatpost.com/living/2021/04/09/the-forgotten-history-of-mal... it says: Dr Mahathir [PM at the time] passed the Malaysian Standard Time Act (1981), which set the clocks ahead 30 minutes on 11.30pm December 31st 1981. New Year\u2019s celebrations came early that year. There's also a summary of the earlier changes, but nothing we didn't already know, and no additional details on exact transition times/dates. kre
Date: Wed, 23 Nov 2022 13:45:31 -0800 From: Paul Eggert <eggert@cs.ucla.edu> Message-ID: <2a8f0009-4d0c-edef-5a00-a3dae9c2a5bb@cs.ucla.edu> | On 11/23/22 12:10, Robert Elz wrote: | > I'd be truly astounded if the same was not also required for | > Asia/Kuala_Lumpur. | | Sure, can you please send something to that effect in 'git format-patch' | format? It'd be a patch to 'backzone'. Thanks. No, I cannot, you know that already, I do not use git, and have nothing which generates git patch format. Moving the data to backzone doesn't mean it needs updating any less than any other data - just makes it harder to remember to do. kre
Steps to produce patch: 1) Go to relevant file: https://github.com/eggert/tz/blob/main/backzone 2) Click edit (pencil) button: https://github.com/eggert/tz/edit/main/backzone 3) Make necessary changes 4) Add git comment in the boxes at the bottom of the page 5) Press "Propose changes" 6) At the "PR rejected" page, add ".patch" to the end of the URL 7) Download the git formatted patch 8) Rename the patch to start with "0001-" 9) Send the patch to the mailing list (disabling PRs makes this much harder than it needs to be) Please see attached, which I request you add to the repository. Now Paul, perhaps you'd like to think whether your choice to be deliberately awkward here rather than making the one line change in `backzone` has been beneficial to anyone, including yourself. You're trying to defend a system which: * causes you to do *more* work - downloading, checking and applying the patch * causes you to send *more* emails to the list: * causes two entries in git history rather than one `backzone` is a file in active use by millions of downstream users. Pretending that isn't true is simply not helpful, and a waste of everyone's time on this mailing list. Stephen On Wed, 23 Nov 2022 at 22:44, Robert Elz via tz <tz@iana.org> wrote:
Date: Wed, 23 Nov 2022 13:45:31 -0800 From: Paul Eggert <eggert@cs.ucla.edu> Message-ID: <2a8f0009-4d0c-edef-5a00-a3dae9c2a5bb@cs.ucla.edu>
| On 11/23/22 12:10, Robert Elz wrote: | > I'd be truly astounded if the same was not also required for | > Asia/Kuala_Lumpur. | | Sure, can you please send something to that effect in 'git format-patch' | format? It'd be a patch to 'backzone'. Thanks.
No, I cannot, you know that already, I do not use git, and have nothing which generates git patch format.
Moving the data to backzone doesn't mean it needs updating any less than any other data - just makes it harder to remember to do.
kre
On 2022-11-28 03:31, Stephen Colebourne via tz wrote:
Please see attached, which I request you add to the repository.
Thanks, I installed that.
perhaps you'd like to think whether your choice to be deliberately awkward here
Actually it's less awkward for me, since if you've made the patch I needn't worry about writing the change, checking it, checking that the comments match the data, etc. And even though running "git format-patch" is a tiny bit more work for you, that's OK if it makes the overall project more scalable. This sort of thing is reasonably common in software projects developed by collaborators. To help document this I installed the attached further patch.
On Mon, 28 Nov 2022 at 20:25, Paul Eggert via tz <tz@iana.org> wrote:
On 2022-11-28 03:31, Stephen Colebourne via tz wrote:
perhaps you'd like to think whether your choice to be deliberately awkward here
Actually it's less awkward for me, since if you've made the patch I needn't worry about writing the change, checking it, checking that the comments match the data, etc. And even though running "git format-patch" is a tiny bit more work for you, that's OK if it makes the overall project more scalable. This sort of thing is reasonably common in software projects developed by collaborators.
I think it is important to document a key difference. I think it is reasonable to ask those who wish to actually maintain data that is *only* in backzone to write patches (although the process is acane because GitHub PRs are switched off). By contrast, the Singapore case is just general maintenance: * you had been made aware of the need to update Singapore in advance * you were already making a change * making the change to Singapore would have resulted in a more logical changeset * making the change to Singapore would have resulted in less churn and emails The goal should be that if you are making a change that affects one of the non-backzone files, but the change also impacts one of the backzone locations, you should also be responsible for updating backzone. Anything else is simply noise and annoyance for the project, and against the long-term health of tzdb. Stephen
On 2022-12-01 01:22, Stephen Colebourne via tz wrote:
if you are making a change that affects one of the non-backzone files, but the change also impacts one of the backzone locations, you should also be responsible for updating backzone.
Surely the responsibility for maintaining data outside TZDB's normal scope should be on those who want the out-of-scope data to be maintained. 'backzone' has long contained lower-quality data, including data inconsistent with the main data. Although I don't have the time or inclination to fix that, if you or someone else does then please feel free to submit patches. Any 'backzone' patches need not be applied simultaneously with patches to the main data; it's OK to take all the time you need to think through how 'backzone' should be improved.
Paul Eggert wrote:
if you are making a change that affects one of the non-backzone files, but the change also impacts one of the backzone locations, you should also be responsible for updating backzone.
Surely the responsibility for maintaining data outside TZDB's normal scope should be on those who want the out-of-scope data to be maintained.
I suspect the real conflict here is that Stephen considers 'backzone' to be within "TZDB's normal scope" and Paul does not, and their respective opinions on this are set in concrete. -- Doug Ewell, CC, ALB | Lakewood, CO, US | ewellic.org
On Thu, 1 Dec 2022 at 21:14, Doug Ewell <doug@ewellic.org> wrote:
I suspect the real conflict here is that Stephen considers 'backzone' to be within "TZDB's normal scope" and Paul does not, and their respective opinions on this are set in concrete.
The separate data for Asia/Singapore and Asia/Kuala_Lumpur was introduced in commit 61315cad in 1993. It was in "TZDB's normal scope" for nearly 30 years until this year (2022). The issue here is that Paul unilaterally decided to alter "TZDB's normal scope" despite many objections. Removing data that has been relied on for 30 years does tend to create tension. Stephen
On 2022-11-23 21:45, Paul Eggert via tz wrote:
Sure, can you please send something to that effect in 'git format-patch' format? It'd be a patch to 'backzone'. Thanks.
I do not understand your policy here: apparently, you seem to avoid obvious corrections before 1970 to timezones when they belong to backzone. Are not the data for these timezones used by zic with the PACKRATLIST option? Why should the resulting files with this option not reflect our best knowledge about civil time at the location of the timezone? Michael Deckers.
On 2022-11-24 03:25, Michael H Deckers via tz wrote:
you seem to avoid obvious corrections before 1970 to timezones when they belong to backzone.
If volunteers step up to maintain backzone by submitting trivially-mergable patches so that I don't have to check or worry about backzone's contents, that's OK. If not, then that's OK too, as backzone is out of the normal scope for tzdb proper and is low priority for this project. My own suggestion would be to not worry about 'backzone' as maintaining it is not worth the effort. But if you'd rather spend that effort, that's fine; please feel free to send a properly-formatted patch.
participants (5)
-
Doug Ewell -
Michael H Deckers -
Paul Eggert -
Robert Elz -
Stephen Colebourne