Skip to content

Fixed TimeZone.init(secondsFromGMT:) failability #1142

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 3 commits into from
Aug 1, 2017

Conversation

bubski
Copy link
Contributor

@bubski bubski commented Jul 29, 2017

TimeZone.init(secondsFromGMT:) made not failable.

Aligns with https://developer.apple.com/documentation/foundation/nstimezone/1387199-init

Fixed TimeZone.init(secondsFromGMT:) failability

@bubski bubski changed the title TimeZone.init(secondsFromGMT:) made not optional TimeZone.init(secondsFromGMT:) made not failable Jul 29, 2017
@ianpartridge
Copy link
Contributor

@bubski
Copy link
Contributor Author

bubski commented Jul 29, 2017

@ianpartridge Ah, you're right. Let's keep it consistent.

I don't understand why it should be failable though. Do you?

@bubski bubski closed this Jul 29, 2017
@ianpartridge
Copy link
Contributor

No I don't know, sorry. Possibly there's a difference in the implementation on Darwin which means it might fail.

@parkera
Copy link
Contributor

parkera commented Jul 29, 2017

let tz = TimeZone(secondsFromGMT: 99999999) -> nil

@parkera
Copy link
Contributor

parkera commented Jul 29, 2017

Here's the relevant line from the Darwin implementation:

if (seconds < -18 * 3600 || 18 * 3600 < seconds) return nil;

@bubski
Copy link
Contributor Author

bubski commented Jul 29, 2017

Ah, interesting.
@parkera Thanks for the context!

Now I see that NSTimeZone(forSecondsFromGMT: 99999999) throws an exception on Darwin's Foundation.
It doesn't on swift-corelibs-foundation, but returns an invalid instance.

also

let tz = TimeZone(secondsFromGMT: 99999999)
tz == nil // false
// And subsequent usage of tz throws exceptions

I assume that's something that needs to be resolved, right?

@bubski
Copy link
Contributor Author

bubski commented Jul 30, 2017

I'm reopening this with a half-way solution.

I'm not sure if it's possible to work around not failable NSTimeZone.init(forSecondsFromGMT:) in Swift, and reproduce Darwin's behavior, which comes from Objective-C interop.

The least we can do I guess, is making TimeZone.init(secondsFromGMT:) fail when expected.

@ianpartridge @parkera please let me know if my reasoning is correct here.

@bubski bubski reopened this Jul 30, 2017
@ianpartridge
Copy link
Contributor

@parkera should we open a Radar if TimeZone(secondsFromGMT:) should be marked failable on Darwin?

@bubski bubski changed the title TimeZone.init(secondsFromGMT:) made not failable Fixed TimeZone.init(secondsFromGMT:) failability Jul 31, 2017
@parkera
Copy link
Contributor

parkera commented Jul 31, 2017

So basically, NSTimeZone has the wrong nullability annotation on Darwin. It does not throw an exception (in Foundation terms); it just returns nil then trying to use it causes a crash as Swift aborts due to using a nil but non-nil result.

This is something that I think I realized when writing the struct TimeZone API, which is why that one is correctly nullable (https://github.com/apple/swift/blob/master/stdlib/public/SDK/Foundation/TimeZone.swift#L71).

For now, for source compatibility, the proposed patch makes sense to me.

@parkera
Copy link
Contributor

parkera commented Jul 31, 2017

And yah, if a radar is filed I can track it -- although frankly I want people to use the struct type here and not the ref type. :)

@ianpartridge
Copy link
Contributor

@parkera Radar 33650342 raised for the incorrect nullable annotation on NSTimeZone.init(forSecondsFromGMT:) on Darwin.

@ianpartridge
Copy link
Contributor

@swift-ci please test and merge

@swift-ci swift-ci merged commit 699d2c9 into swiftlang:master Aug 1, 2017
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.

4 participants