GH-43808: [C++] skip -0117 in StrptimeZoneOffset for old glibc

[h-vetinari]

Rationale for this change

Enable tests for libarrow in conda-forge: #35587

What changes are included in this PR?

old glibc does not actually support timezones like -0117 (used in StrptimeZoneOffset test). The exact lower bound for glibc is hard for me to determine; I know that it passes with 2.28 and that it fails with 2.17. Anything in between is an open question. I went with the conservative option here.

Are these changes tested?

Tested in conda-forge/arrow-cpp-feedstock#1058

Are there any user-facing changes?

• GitHub Issue: [C++] Skip TimestampParser.StrptimeZoneOffset with old glibc #43808

[github-actions]

⚠️ GitHub issue #43808 has been automatically assigned in GitHub to PR creator.

[h-vetinari]

PTAL @kou :)

CC @pitrou

[github-actions]

⚠️ GitHub issue #43808 has been automatically assigned in GitHub to PR creator.

[kou]

Hmm. It seems that we need to improve the added condition...

Java JNI / AMD64 manylinux2014 Java JNI: https://github.com/apache/arrow/actions/runs/11692780048/job/32562887155?pr=44621#step:7:3448

[ RUN      ] TimestampConversion.UserDefinedParsersWithZone
/arrow/cpp/src/arrow/csv/converter_test.cc:169: Failure
Failed
Expected 'converter->Convert(*parser, i)' to fail with Invalid, but got OK
/arrow/cpp/src/arrow/csv/converter_test.cc:169: Failure
Failed
Expected 'converter->Convert(*parser, i)' to fail with Invalid, but got OK
[  FAILED  ] TimestampConversion.UserDefinedParsersWithZone (0 ms)

C++ / AMD64 Conda C++ AVX2: https://github.com/apache/arrow/actions/runs/11692780055/job/32562895558?pr=44621#step:7:4505

[ RUN      ] TimestampConversion.UserDefinedParsersWithZone
/arrow/cpp/src/arrow/csv/converter_test.cc:169: Failure
Failed
Expected 'converter->Convert(*parser, i)' to fail with Invalid, but got OK
/arrow/cpp/src/arrow/csv/converter_test.cc:169: Failure
Failed
Expected 'converter->Convert(*parser, i)' to fail with Invalid, but got OK
[  FAILED  ] TimestampConversion.UserDefinedParsersWithZone (0 ms)

[h-vetinari]

Hmm. It seems that we need to improve the added condition...

Or just the test expectations need to depend on kStrptimeSupportsZone?

[h-vetinari]

FWIW, I don't mind how this is done. We could also add

#if defined(__GLIBC__) && defined(__GLIBC_MINOR__) && (__GLIBC__ == 2) && (__GLIBC_MINOR__ < 28)

in

arrow/cpp/src/arrow/util/value_parsing_test.cc

Lines 829 to 832 in 11c11a4

	TEST(TimestampParser, StrptimeZoneOffset) {
	if (!kStrptimeSupportsZone) {
	GTEST_SKIP() << "strptime does not support %z on this platform";
	}

directly, but the reason I went with this is that my understanding is that it's unlike that old glibc actually supports this feature, and we might as well reflect that...?

[kou]

I think that the test failure shows that glibc used by these CI supports %z in strptime(). (Right?)
If so, we should set kStrptimeSupportsZone to true for the glibc.

[github-actions]

⚠️ GitHub issue #43808 has been automatically assigned in GitHub to PR creator.

[h-vetinari]

If so, we should set kStrptimeSupportsZone to true for the glibc.

You're right, that existing skip was a red herring. I think the only issue is with the -0117 timezone.

[h-vetinari]

Gentle ping @kou

[raulcd]

The AMD64 Windows MinGW CLANG64 C++ job has just started failing but it does not seem related to the changes on the PR.

[kou]

It's unrelated. I've opened a new issue for it: #44730

[kou]

@h-vetinari Could you update the PR description before we merge this?

[h-vetinari]

@h-vetinari Could you update the PR description before we merge this?

Done

[github-actions]

⚠️ GitHub issue #43808 has been automatically assigned in GitHub to PR creator.