[ruby-core:111220] [Ruby master Bug#19187] Ruby 3.1.3 testsuite fails after timezone 2022g update is applied

Issue #19187 has been reported by coolo (Stephan Kulow). ---------------------------------------- Bug #19187: Ruby 3.1.3 testsuite fails after timezone 2022g update is applied https://bugs.ruby-lang.org/issues/19187 * Author: coolo (Stephan Kulow) * Status: Open * Priority: Normal * ruby -v: ruby 3.1.3p185 (2022-11-24 revision 1a6b16756e) [x86_64-linux-gnu] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- The timezone database changed incompatible to what ruby's testsuite expects. See the announcement here: http://mm.icann.org/pipermail/tz-announce/2022-November/000076.html and note the little detail Singapore's 1981-12-31 change was at 16:00 UTC (23:30 local time), not 24:00 local time. (Thanks to Geoff Clare via Robert Elz.) Problem is that test/ruby/test_time_tz.rb tests this very detail in 3 places - and breaks. 1) Failure: TestTimeTZ#test_asia_singapore [/home/abuild/rpmbuild/BUILD/ruby-3.1.3/test/ruby/test_time_tz.rb:143]: TZ=Asia/Singapore Time.local(1981, 12, 31, 23, 59, 59). <"1981-12-31 23:59:59 +0730"> expected but was <"1982-01-01 00:29:59 +0800">. 2) Failure: TestTimeTZ#test_gen_Asia_Singapore_22 [/home/abuild/rpmbuild/BUILD/ruby-3.1.3/test/ruby/test_time_tz.rb:382]: TZ=Asia/Singapore Time.utc(1981, 12, 31, 16, 29, 59).localtime. <"1981-12-31 23:59:59 +0730"> expected but was <"1982-01-01 00:29:59 +0800">. 3) Failure: TestTimeTZ#test_gen_Asia_Singapore_45 [/home/abuild/rpmbuild/BUILD/ruby-3.1.3/test/ruby/test_time_tz.rb:400]: TZ=Asia/Singapore Time.local(1981, 12, 31, 23, 59, 59). <"1981-12-31 23:59:59 +0730"> expected but was <"1982-01-01 00:29:59 +0800">. I can see no other option than not to test this detail - because relying on correct timezone data (either way) is barely possible. -- https://bugs.ruby-lang.org/

Issue #19187 has been updated by nagachika (Tomoyuki Chikanaga). Status changed from Open to Closed Backport changed from 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN to 2.7: REQUIRED, 3.0: REQUIRED, 3.1: REQUIRED The workaround was committed to master branch at 58cc3c9f387dcf8f820b43e043b540fa06248da3. ---------------------------------------- Bug #19187: Ruby 3.1.3 testsuite fails after timezone 2022g update is applied https://bugs.ruby-lang.org/issues/19187#change-100518 * Author: coolo (Stephan Kulow) * Status: Closed * Priority: Normal * ruby -v: ruby 3.1.3p185 (2022-11-24 revision 1a6b16756e) [x86_64-linux-gnu] * Backport: 2.7: REQUIRED, 3.0: REQUIRED, 3.1: REQUIRED ---------------------------------------- The timezone database changed incompatible to what ruby's testsuite expects. See the announcement here: http://mm.icann.org/pipermail/tz-announce/2022-November/000076.html and note the little detail Singapore's 1981-12-31 change was at 16:00 UTC (23:30 local time), not 24:00 local time. (Thanks to Geoff Clare via Robert Elz.) Problem is that test/ruby/test_time_tz.rb tests this very detail in 3 places - and breaks. 1) Failure: TestTimeTZ#test_asia_singapore [/home/abuild/rpmbuild/BUILD/ruby-3.1.3/test/ruby/test_time_tz.rb:143]: TZ=Asia/Singapore Time.local(1981, 12, 31, 23, 59, 59). <"1981-12-31 23:59:59 +0730"> expected but was <"1982-01-01 00:29:59 +0800">. 2) Failure: TestTimeTZ#test_gen_Asia_Singapore_22 [/home/abuild/rpmbuild/BUILD/ruby-3.1.3/test/ruby/test_time_tz.rb:382]: TZ=Asia/Singapore Time.utc(1981, 12, 31, 16, 29, 59).localtime. <"1981-12-31 23:59:59 +0730"> expected but was <"1982-01-01 00:29:59 +0800">. 3) Failure: TestTimeTZ#test_gen_Asia_Singapore_45 [/home/abuild/rpmbuild/BUILD/ruby-3.1.3/test/ruby/test_time_tz.rb:400]: TZ=Asia/Singapore Time.local(1981, 12, 31, 23, 59, 59). <"1981-12-31 23:59:59 +0730"> expected but was <"1982-01-01 00:29:59 +0800">. I can see no other option than not to test this detail - because relying on correct timezone data (either way) is barely possible. -- https://bugs.ruby-lang.org/

Issue #19187 has been updated by nobu (Nobuyoshi Nakada). coolo (Stephan Kulow) wrote:
I can see no other option than not to test this detail - because relying on correct timezone data (either way) is barely possible.
I agree that we should not test tzdata itself. https://github.com/nobu/ruby/tree/tzdata-nitpick ---------------------------------------- Bug #19187: Ruby 3.1.3 testsuite fails after timezone 2022g update is applied https://bugs.ruby-lang.org/issues/19187#change-100520 * Author: coolo (Stephan Kulow) * Status: Closed * Priority: Normal * ruby -v: ruby 3.1.3p185 (2022-11-24 revision 1a6b16756e) [x86_64-linux-gnu] * Backport: 2.7: REQUIRED, 3.0: REQUIRED, 3.1: REQUIRED ---------------------------------------- The timezone database changed incompatible to what ruby's testsuite expects. See the announcement here: http://mm.icann.org/pipermail/tz-announce/2022-November/000076.html and note the little detail Singapore's 1981-12-31 change was at 16:00 UTC (23:30 local time), not 24:00 local time. (Thanks to Geoff Clare via Robert Elz.) Problem is that test/ruby/test_time_tz.rb tests this very detail in 3 places - and breaks. 1) Failure: TestTimeTZ#test_asia_singapore [/home/abuild/rpmbuild/BUILD/ruby-3.1.3/test/ruby/test_time_tz.rb:143]: TZ=Asia/Singapore Time.local(1981, 12, 31, 23, 59, 59). <"1981-12-31 23:59:59 +0730"> expected but was <"1982-01-01 00:29:59 +0800">. 2) Failure: TestTimeTZ#test_gen_Asia_Singapore_22 [/home/abuild/rpmbuild/BUILD/ruby-3.1.3/test/ruby/test_time_tz.rb:382]: TZ=Asia/Singapore Time.utc(1981, 12, 31, 16, 29, 59).localtime. <"1981-12-31 23:59:59 +0730"> expected but was <"1982-01-01 00:29:59 +0800">. 3) Failure: TestTimeTZ#test_gen_Asia_Singapore_45 [/home/abuild/rpmbuild/BUILD/ruby-3.1.3/test/ruby/test_time_tz.rb:400]: TZ=Asia/Singapore Time.local(1981, 12, 31, 23, 59, 59). <"1981-12-31 23:59:59 +0730"> expected but was <"1982-01-01 00:29:59 +0800">. I can see no other option than not to test this detail - because relying on correct timezone data (either way) is barely possible. -- https://bugs.ruby-lang.org/

Issue #19187 has been updated by usa (Usaku NAKAMURA). Backport changed from 2.7: REQUIRED, 3.0: REQUIRED, 3.1: REQUIRED to 2.7: DONE, 3.0: REQUIRED, 3.1: REQUIRED ruby_2_7 36cadad6434bc31bc2d60697698cd5b930c097ce merged revision(s) 58cc3c9f. ---------------------------------------- Bug #19187: Ruby 3.1.3 testsuite fails after timezone 2022g update is applied https://bugs.ruby-lang.org/issues/19187#change-100525 * Author: coolo (Stephan Kulow) * Status: Closed * Priority: Normal * ruby -v: ruby 3.1.3p185 (2022-11-24 revision 1a6b16756e) [x86_64-linux-gnu] * Backport: 2.7: DONE, 3.0: REQUIRED, 3.1: REQUIRED ---------------------------------------- The timezone database changed incompatible to what ruby's testsuite expects. See the announcement here: http://mm.icann.org/pipermail/tz-announce/2022-November/000076.html and note the little detail Singapore's 1981-12-31 change was at 16:00 UTC (23:30 local time), not 24:00 local time. (Thanks to Geoff Clare via Robert Elz.) Problem is that test/ruby/test_time_tz.rb tests this very detail in 3 places - and breaks. 1) Failure: TestTimeTZ#test_asia_singapore [/home/abuild/rpmbuild/BUILD/ruby-3.1.3/test/ruby/test_time_tz.rb:143]: TZ=Asia/Singapore Time.local(1981, 12, 31, 23, 59, 59). <"1981-12-31 23:59:59 +0730"> expected but was <"1982-01-01 00:29:59 +0800">. 2) Failure: TestTimeTZ#test_gen_Asia_Singapore_22 [/home/abuild/rpmbuild/BUILD/ruby-3.1.3/test/ruby/test_time_tz.rb:382]: TZ=Asia/Singapore Time.utc(1981, 12, 31, 16, 29, 59).localtime. <"1981-12-31 23:59:59 +0730"> expected but was <"1982-01-01 00:29:59 +0800">. 3) Failure: TestTimeTZ#test_gen_Asia_Singapore_45 [/home/abuild/rpmbuild/BUILD/ruby-3.1.3/test/ruby/test_time_tz.rb:400]: TZ=Asia/Singapore Time.local(1981, 12, 31, 23, 59, 59). <"1981-12-31 23:59:59 +0730"> expected but was <"1982-01-01 00:29:59 +0800">. I can see no other option than not to test this detail - because relying on correct timezone data (either way) is barely possible. -- https://bugs.ruby-lang.org/

Issue #19187 has been updated by usa (Usaku NAKAMURA). Backport changed from 2.7: DONE, 3.0: REQUIRED, 3.1: REQUIRED to 2.7: DONE, 3.0: DONE, 3.1: REQUIRED ruby_3_0 a0a99185577794b1915eba0dc5154f09cc95e81d merged revision(s) 58cc3c9f. ---------------------------------------- Bug #19187: Ruby 3.1.3 testsuite fails after timezone 2022g update is applied https://bugs.ruby-lang.org/issues/19187#change-100526 * Author: coolo (Stephan Kulow) * Status: Closed * Priority: Normal * ruby -v: ruby 3.1.3p185 (2022-11-24 revision 1a6b16756e) [x86_64-linux-gnu] * Backport: 2.7: DONE, 3.0: DONE, 3.1: REQUIRED ---------------------------------------- The timezone database changed incompatible to what ruby's testsuite expects. See the announcement here: http://mm.icann.org/pipermail/tz-announce/2022-November/000076.html and note the little detail Singapore's 1981-12-31 change was at 16:00 UTC (23:30 local time), not 24:00 local time. (Thanks to Geoff Clare via Robert Elz.) Problem is that test/ruby/test_time_tz.rb tests this very detail in 3 places - and breaks. 1) Failure: TestTimeTZ#test_asia_singapore [/home/abuild/rpmbuild/BUILD/ruby-3.1.3/test/ruby/test_time_tz.rb:143]: TZ=Asia/Singapore Time.local(1981, 12, 31, 23, 59, 59). <"1981-12-31 23:59:59 +0730"> expected but was <"1982-01-01 00:29:59 +0800">. 2) Failure: TestTimeTZ#test_gen_Asia_Singapore_22 [/home/abuild/rpmbuild/BUILD/ruby-3.1.3/test/ruby/test_time_tz.rb:382]: TZ=Asia/Singapore Time.utc(1981, 12, 31, 16, 29, 59).localtime. <"1981-12-31 23:59:59 +0730"> expected but was <"1982-01-01 00:29:59 +0800">. 3) Failure: TestTimeTZ#test_gen_Asia_Singapore_45 [/home/abuild/rpmbuild/BUILD/ruby-3.1.3/test/ruby/test_time_tz.rb:400]: TZ=Asia/Singapore Time.local(1981, 12, 31, 23, 59, 59). <"1981-12-31 23:59:59 +0730"> expected but was <"1982-01-01 00:29:59 +0800">. I can see no other option than not to test this detail - because relying on correct timezone data (either way) is barely possible. -- https://bugs.ruby-lang.org/

Issue #19187 has been updated by nagachika (Tomoyuki Chikanaga). Backport changed from 2.7: DONE, 3.0: DONE, 3.1: REQUIRED to 2.7: DONE, 3.0: DONE, 3.1: DONE ruby_3_1 a1124dc162810f86cb0bff58cde24064cfc561bc merged revision(s) 58cc3c9f387dcf8f820b43e043b540fa06248da3. ---------------------------------------- Bug #19187: Ruby 3.1.3 testsuite fails after timezone 2022g update is applied https://bugs.ruby-lang.org/issues/19187#change-100536 * Author: coolo (Stephan Kulow) * Status: Closed * Priority: Normal * ruby -v: ruby 3.1.3p185 (2022-11-24 revision 1a6b16756e) [x86_64-linux-gnu] * Backport: 2.7: DONE, 3.0: DONE, 3.1: DONE ---------------------------------------- The timezone database changed incompatible to what ruby's testsuite expects. See the announcement here: http://mm.icann.org/pipermail/tz-announce/2022-November/000076.html and note the little detail Singapore's 1981-12-31 change was at 16:00 UTC (23:30 local time), not 24:00 local time. (Thanks to Geoff Clare via Robert Elz.) Problem is that test/ruby/test_time_tz.rb tests this very detail in 3 places - and breaks. 1) Failure: TestTimeTZ#test_asia_singapore [/home/abuild/rpmbuild/BUILD/ruby-3.1.3/test/ruby/test_time_tz.rb:143]: TZ=Asia/Singapore Time.local(1981, 12, 31, 23, 59, 59). <"1981-12-31 23:59:59 +0730"> expected but was <"1982-01-01 00:29:59 +0800">. 2) Failure: TestTimeTZ#test_gen_Asia_Singapore_22 [/home/abuild/rpmbuild/BUILD/ruby-3.1.3/test/ruby/test_time_tz.rb:382]: TZ=Asia/Singapore Time.utc(1981, 12, 31, 16, 29, 59).localtime. <"1981-12-31 23:59:59 +0730"> expected but was <"1982-01-01 00:29:59 +0800">. 3) Failure: TestTimeTZ#test_gen_Asia_Singapore_45 [/home/abuild/rpmbuild/BUILD/ruby-3.1.3/test/ruby/test_time_tz.rb:400]: TZ=Asia/Singapore Time.local(1981, 12, 31, 23, 59, 59). <"1981-12-31 23:59:59 +0730"> expected but was <"1982-01-01 00:29:59 +0800">. I can see no other option than not to test this detail - because relying on correct timezone data (either way) is barely possible. -- https://bugs.ruby-lang.org/

Issue #19187 has been updated by vo.x (Vit Ondruch). nobu (Nobuyoshi Nakada) wrote in #note-2:
coolo (Stephan Kulow) wrote:
I can see no other option than not to test this detail - because relying on correct timezone data (either way) is barely possible.
I agree that we should not test tzdata itself. https://github.com/nobu/ruby/tree/tzdata-nitpick
Was this proposal forgotten or is this going to land? ---------------------------------------- Bug #19187: Ruby 3.1.3 testsuite fails after timezone 2022g update is applied https://bugs.ruby-lang.org/issues/19187#change-100736 * Author: coolo (Stephan Kulow) * Status: Closed * Priority: Normal * ruby -v: ruby 3.1.3p185 (2022-11-24 revision 1a6b16756e) [x86_64-linux-gnu] * Backport: 2.7: DONE, 3.0: DONE, 3.1: DONE ---------------------------------------- The timezone database changed incompatible to what ruby's testsuite expects. See the announcement here: http://mm.icann.org/pipermail/tz-announce/2022-November/000076.html and note the little detail Singapore's 1981-12-31 change was at 16:00 UTC (23:30 local time), not 24:00 local time. (Thanks to Geoff Clare via Robert Elz.) Problem is that test/ruby/test_time_tz.rb tests this very detail in 3 places - and breaks. 1) Failure: TestTimeTZ#test_asia_singapore [/home/abuild/rpmbuild/BUILD/ruby-3.1.3/test/ruby/test_time_tz.rb:143]: TZ=Asia/Singapore Time.local(1981, 12, 31, 23, 59, 59). <"1981-12-31 23:59:59 +0730"> expected but was <"1982-01-01 00:29:59 +0800">. 2) Failure: TestTimeTZ#test_gen_Asia_Singapore_22 [/home/abuild/rpmbuild/BUILD/ruby-3.1.3/test/ruby/test_time_tz.rb:382]: TZ=Asia/Singapore Time.utc(1981, 12, 31, 16, 29, 59).localtime. <"1981-12-31 23:59:59 +0730"> expected but was <"1982-01-01 00:29:59 +0800">. 3) Failure: TestTimeTZ#test_gen_Asia_Singapore_45 [/home/abuild/rpmbuild/BUILD/ruby-3.1.3/test/ruby/test_time_tz.rb:400]: TZ=Asia/Singapore Time.local(1981, 12, 31, 23, 59, 59). <"1981-12-31 23:59:59 +0730"> expected but was <"1982-01-01 00:29:59 +0800">. I can see no other option than not to test this detail - because relying on correct timezone data (either way) is barely possible. -- https://bugs.ruby-lang.org/

Issue #19187 has been updated by mame (Yusuke Endoh). I disagree with simply erasing the tests depending on tzdata. We need to test our logic to handle leap seconds, etc. If we remove the dependency on tzdata, I think we need to mock tzdata and test our logic. But we don't have to go that far. I think using tzdata is good enough. Following changes in tzdata is a bit annoying, but I don't think it's happening so frequently. ---------------------------------------- Bug #19187: Ruby 3.1.3 testsuite fails after timezone 2022g update is applied https://bugs.ruby-lang.org/issues/19187#change-100753 * Author: coolo (Stephan Kulow) * Status: Closed * Priority: Normal * ruby -v: ruby 3.1.3p185 (2022-11-24 revision 1a6b16756e) [x86_64-linux-gnu] * Backport: 2.7: DONE, 3.0: DONE, 3.1: DONE ---------------------------------------- The timezone database changed incompatible to what ruby's testsuite expects. See the announcement here: http://mm.icann.org/pipermail/tz-announce/2022-November/000076.html and note the little detail Singapore's 1981-12-31 change was at 16:00 UTC (23:30 local time), not 24:00 local time. (Thanks to Geoff Clare via Robert Elz.) Problem is that test/ruby/test_time_tz.rb tests this very detail in 3 places - and breaks. 1) Failure: TestTimeTZ#test_asia_singapore [/home/abuild/rpmbuild/BUILD/ruby-3.1.3/test/ruby/test_time_tz.rb:143]: TZ=Asia/Singapore Time.local(1981, 12, 31, 23, 59, 59). <"1981-12-31 23:59:59 +0730"> expected but was <"1982-01-01 00:29:59 +0800">. 2) Failure: TestTimeTZ#test_gen_Asia_Singapore_22 [/home/abuild/rpmbuild/BUILD/ruby-3.1.3/test/ruby/test_time_tz.rb:382]: TZ=Asia/Singapore Time.utc(1981, 12, 31, 16, 29, 59).localtime. <"1981-12-31 23:59:59 +0730"> expected but was <"1982-01-01 00:29:59 +0800">. 3) Failure: TestTimeTZ#test_gen_Asia_Singapore_45 [/home/abuild/rpmbuild/BUILD/ruby-3.1.3/test/ruby/test_time_tz.rb:400]: TZ=Asia/Singapore Time.local(1981, 12, 31, 23, 59, 59). <"1981-12-31 23:59:59 +0730"> expected but was <"1982-01-01 00:29:59 +0800">. I can see no other option than not to test this detail - because relying on correct timezone data (either way) is barely possible. -- https://bugs.ruby-lang.org/

Issue #19187 has been updated by duerst (Martin Dürst). mame (Yusuke Endoh) wrote in #note-7:
I disagree with simply erasing the tests depending on tzdata.
Following changes in tzdata is a bit annoying, but I don't think it's happening so frequently.
I agree. In particular, this test was for 1981. Data about 1981 should only change very infrequently, essentially only when a mistake in tzdata is detected and fixed. ---------------------------------------- Bug #19187: Ruby 3.1.3 testsuite fails after timezone 2022g update is applied https://bugs.ruby-lang.org/issues/19187#change-100754 * Author: coolo (Stephan Kulow) * Status: Closed * Priority: Normal * ruby -v: ruby 3.1.3p185 (2022-11-24 revision 1a6b16756e) [x86_64-linux-gnu] * Backport: 2.7: DONE, 3.0: DONE, 3.1: DONE ---------------------------------------- The timezone database changed incompatible to what ruby's testsuite expects. See the announcement here: http://mm.icann.org/pipermail/tz-announce/2022-November/000076.html and note the little detail Singapore's 1981-12-31 change was at 16:00 UTC (23:30 local time), not 24:00 local time. (Thanks to Geoff Clare via Robert Elz.) Problem is that test/ruby/test_time_tz.rb tests this very detail in 3 places - and breaks. 1) Failure: TestTimeTZ#test_asia_singapore [/home/abuild/rpmbuild/BUILD/ruby-3.1.3/test/ruby/test_time_tz.rb:143]: TZ=Asia/Singapore Time.local(1981, 12, 31, 23, 59, 59). <"1981-12-31 23:59:59 +0730"> expected but was <"1982-01-01 00:29:59 +0800">. 2) Failure: TestTimeTZ#test_gen_Asia_Singapore_22 [/home/abuild/rpmbuild/BUILD/ruby-3.1.3/test/ruby/test_time_tz.rb:382]: TZ=Asia/Singapore Time.utc(1981, 12, 31, 16, 29, 59).localtime. <"1981-12-31 23:59:59 +0730"> expected but was <"1982-01-01 00:29:59 +0800">. 3) Failure: TestTimeTZ#test_gen_Asia_Singapore_45 [/home/abuild/rpmbuild/BUILD/ruby-3.1.3/test/ruby/test_time_tz.rb:400]: TZ=Asia/Singapore Time.local(1981, 12, 31, 23, 59, 59). <"1981-12-31 23:59:59 +0730"> expected but was <"1982-01-01 00:29:59 +0800">. I can see no other option than not to test this detail - because relying on correct timezone data (either way) is barely possible. -- https://bugs.ruby-lang.org/

Issue #19187 has been updated by nobu (Nobuyoshi Nakada). mame (Yusuke Endoh) wrote in #note-7:
We need to test our logic to handle leap seconds, etc. If we remove the dependency on tzdata, I think we need to mock tzdata and test our logic.
I understand your concern, but the changes in [GH-6990] should be unrelated to leap seconds. [GH-6990]: https://github.com/ruby/ruby/pull/6990 ---------------------------------------- Bug #19187: Ruby 3.1.3 testsuite fails after timezone 2022g update is applied https://bugs.ruby-lang.org/issues/19187#change-100755 * Author: coolo (Stephan Kulow) * Status: Closed * Priority: Normal * ruby -v: ruby 3.1.3p185 (2022-11-24 revision 1a6b16756e) [x86_64-linux-gnu] * Backport: 2.7: DONE, 3.0: DONE, 3.1: DONE ---------------------------------------- The timezone database changed incompatible to what ruby's testsuite expects. See the announcement here: http://mm.icann.org/pipermail/tz-announce/2022-November/000076.html and note the little detail Singapore's 1981-12-31 change was at 16:00 UTC (23:30 local time), not 24:00 local time. (Thanks to Geoff Clare via Robert Elz.) Problem is that test/ruby/test_time_tz.rb tests this very detail in 3 places - and breaks. 1) Failure: TestTimeTZ#test_asia_singapore [/home/abuild/rpmbuild/BUILD/ruby-3.1.3/test/ruby/test_time_tz.rb:143]: TZ=Asia/Singapore Time.local(1981, 12, 31, 23, 59, 59). <"1981-12-31 23:59:59 +0730"> expected but was <"1982-01-01 00:29:59 +0800">. 2) Failure: TestTimeTZ#test_gen_Asia_Singapore_22 [/home/abuild/rpmbuild/BUILD/ruby-3.1.3/test/ruby/test_time_tz.rb:382]: TZ=Asia/Singapore Time.utc(1981, 12, 31, 16, 29, 59).localtime. <"1981-12-31 23:59:59 +0730"> expected but was <"1982-01-01 00:29:59 +0800">. 3) Failure: TestTimeTZ#test_gen_Asia_Singapore_45 [/home/abuild/rpmbuild/BUILD/ruby-3.1.3/test/ruby/test_time_tz.rb:400]: TZ=Asia/Singapore Time.local(1981, 12, 31, 23, 59, 59). <"1981-12-31 23:59:59 +0730"> expected but was <"1982-01-01 00:29:59 +0800">. I can see no other option than not to test this detail - because relying on correct timezone data (either way) is barely possible. -- https://bugs.ruby-lang.org/

Issue #19187 has been updated by vo.x (Vit Ondruch). I have opened #19251 to discuss the followup. ---------------------------------------- Bug #19187: Ruby 3.1.3 testsuite fails after timezone 2022g update is applied https://bugs.ruby-lang.org/issues/19187#change-100757 * Author: coolo (Stephan Kulow) * Status: Closed * Priority: Normal * ruby -v: ruby 3.1.3p185 (2022-11-24 revision 1a6b16756e) [x86_64-linux-gnu] * Backport: 2.7: DONE, 3.0: DONE, 3.1: DONE ---------------------------------------- The timezone database changed incompatible to what ruby's testsuite expects. See the announcement here: http://mm.icann.org/pipermail/tz-announce/2022-November/000076.html and note the little detail Singapore's 1981-12-31 change was at 16:00 UTC (23:30 local time), not 24:00 local time. (Thanks to Geoff Clare via Robert Elz.) Problem is that test/ruby/test_time_tz.rb tests this very detail in 3 places - and breaks. 1) Failure: TestTimeTZ#test_asia_singapore [/home/abuild/rpmbuild/BUILD/ruby-3.1.3/test/ruby/test_time_tz.rb:143]: TZ=Asia/Singapore Time.local(1981, 12, 31, 23, 59, 59). <"1981-12-31 23:59:59 +0730"> expected but was <"1982-01-01 00:29:59 +0800">. 2) Failure: TestTimeTZ#test_gen_Asia_Singapore_22 [/home/abuild/rpmbuild/BUILD/ruby-3.1.3/test/ruby/test_time_tz.rb:382]: TZ=Asia/Singapore Time.utc(1981, 12, 31, 16, 29, 59).localtime. <"1981-12-31 23:59:59 +0730"> expected but was <"1982-01-01 00:29:59 +0800">. 3) Failure: TestTimeTZ#test_gen_Asia_Singapore_45 [/home/abuild/rpmbuild/BUILD/ruby-3.1.3/test/ruby/test_time_tz.rb:400]: TZ=Asia/Singapore Time.local(1981, 12, 31, 23, 59, 59). <"1981-12-31 23:59:59 +0730"> expected but was <"1982-01-01 00:29:59 +0800">. I can see no other option than not to test this detail - because relying on correct timezone data (either way) is barely possible. -- https://bugs.ruby-lang.org/
participants (7)
-
coolo (Stephan Kulow)
-
duerst
-
mame (Yusuke Endoh)
-
nagachika (Tomoyuki Chikanaga)
-
nobu (Nobuyoshi Nakada)
-
usa (Usaku NAKAMURA)
-
vo.x (Vit Ondruch)