Skip to content

Flips a conditional check when parsing time zone data. #126

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Dec 16, 2015
Merged

Flips a conditional check when parsing time zone data. #126

merged 1 commit into from
Dec 16, 2015

Conversation

brownleej
Copy link

No description provided.

@@ -1079,7 +1079,7 @@ Boolean _CFTimeZoneInit(CFTimeZoneRef timeZone, CFStringRef name, CFDataRef data
CFTZPeriod *tzp = NULL;
CFIndex cnt = 0;
__CFTimeZoneLockGlobal();
if (!__CFParseTimeZoneData(kCFAllocatorSystemDefault, data, &tzp, &cnt)) {
if (__CFParseTimeZoneData(kCFAllocatorSystemDefault, data, &tzp, &cnt)) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice catch.

@parkera
Copy link
Contributor

parkera commented Dec 12, 2015

Unfortunately our handling of time zones on Ubuntu 14.04 at least is broken; CFTimeZone.c does not fall back to localtime() or similar if the file at /etc/localtime is not a symlink. So this test fails on Linux at the moment.

@parkera
Copy link
Contributor

parkera commented Dec 12, 2015

I pushed a commit to start towards a fix of the last thing, but it's still not enough yet.

	Fixes a type in the the tryParseGMTName function.
@brownleej
Copy link
Author

I think I've found the issue. The tryParseGMTName function was using a Boolean for something that needed be a String index, and this seems to behave differently on Linux than on Mac OS, and restricts the values to 0 or 1. I've updated the commit with a fix for this, and the tests are passing on my Linux install.

@brownleej
Copy link
Author

This commit also takes a lot of shorthands because the tests only use a GMT+XXXX time zone, rather than a proper named one. My main motivation for this patch is that it will provide enough time zone support to address SR-171, which causes test failures on both Mac and Linux when the system time is around GMT+11. I'm hoping to take some time to work on named time zone support next, but it'll be tricky because Ubuntu uses TZIF2 time zone files, so there will need to be new code for parsing that format. I've played around with named time zones in Ubuntu a bit, and it looks to me like all they need is this fix and a fix for SR-190. The TZIF2 format is backwards compatible with TZIF1 parsers, though we'll need special TZIF2 parsing code to support DST transitions after 2038.

@parkera parkera self-assigned this Dec 13, 2015
@parkera
Copy link
Contributor

parkera commented Dec 16, 2015

I have a fix pending for SR-190, then I'll revisit this with that in place.

@parkera
Copy link
Contributor

parkera commented Dec 16, 2015

Thanks for getting to the bottom of that string encoding conversion bug.

@parkera parkera merged commit bc4cea0 into swiftlang:master Dec 16, 2015
@brownleej brownleej deleted the time-zone-initialization-fix branch December 17, 2015 00:21
atrick pushed a commit to atrick/swift-corelibs-foundation that referenced this pull request Jan 12, 2021
Implement "textDocument/implementation" request
kateinoigakukun pushed a commit to kateinoigakukun/swift-corelibs-foundation that referenced this pull request Oct 11, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants