get device TimeZone as America/Los_Angeles format

I need the timezone of the device for a registration flow. It get's submitted to a backend server.

I setup a device and adjusted the TimeZone to San Francisco and tried the following.
Code Block swift
let identifier = TimeZone.current.identifier

The identifier is US/Pacific - looking nice to me.
But the server developer isn't happy about that. He expects the format America/Los_Angeles

I tried to get that fomat but failed, any solution to the issue?

get device TimeZone as America/Los_Angeles format

What platform are you working on?

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
iPadOs 14.4.x up to 14.5.x
Well, that’s interesting. According to the tz database US/Pacific is a deprecated link to America/Los_Angeles, and thus it makes sense that it doesn’t show up in knownTimeZoneIdentifiers. What doesn’t make sense is that we’d return TimeZone.current that way, but I suspect that’s a compatibility affordance. Notably, this isn’t a change in iOS 14 but is also the case in iOS 13.

As to how you can get from one to the other, that’s tricky. I have some ideas on that front but I’m reluctant to suggest a concrete workaround without more research. And that’s hard to do in the context of DevForums, alas. Please open a DTS tech support incident so that I can allocate the time for that research.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
I created a DTS, it Follow-up: 769041707
Thanks. It just landed in my queue and I’ll respond there tomorrow.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

I am curious if you were able to get to the root of this. I am seeing similar issue where I am getting US/Pacific returned and not America/Los_Angeles for TimeZone.current.identifier

It’s hard to be sure. As noted above, FunkyMusic opened a DTS TSI for this and I did investigate it in depth. Unfortunately they never responded to my emails, so I’m not sure whether my answer was sufficient )-:

Anyway, my conclusions:

  • I don’t believe there’s a easy way to get the canonical identifier you’re looking for (that is, America/Los_Angeles rather than US/Pacific).

  • I encourage you to file an enhancement request against Foundation asking for a better way to handle this. Please post your bug number, just for the record.

  • In the meantime, you can get the canonical identifier by looking through the known time zones (knownTimeZoneIdentifiers) for time zones whose zone data matches the zone data of the current time zone.

For example:

extension TimeZone {
    var aliasIdentifiers: [String] {
        let ourID = self.identifier
        let ourSecondsFromGMT = self.secondsFromGMT()
        let ourData = (self as NSTimeZone).data
        return TimeZone.knownTimeZoneIdentifiers
            // Ignore ourselves.
            .filter { otherID in otherID != ourID }
            // Build a `TimeZone` from the ID.
            .compactMap { otherID in TimeZone(identifier: otherID) }
            // It must have the right GMT offset.
            .filter { otherZone in otherZone.secondsFromGMT() == ourSecondsFromGMT }
            // and matching zone data.
            .filter { otherZone in (otherZone as NSTimeZone).data == ourData }
            // Finally return the ID.
            .map { otherZone in otherZone.identifier }
    }
}

I had to exploit the toll-free bridge between TimeZone and NSTimeZone because the data property is only available on the latter.

IMPORTANT This workaround is not the most efficient code so I recommend that you profile your performance and then cache the value if necessary.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

I am seeing similar issue where I am getting aliases returned instead of "Region/City" for TimeZone.current.identifier, is this issue resolved or is the workaround still recommended?

get device TimeZone as America/Los_Angeles format
 
 
Q