You are very much in the weeds, alas. First things first, an NSDate represents an absolute point in time as a floating point offset in seconds from the reference date (the beginning of 2001, UTC). NSDate are always UTC; time zones are never involved.
In Foundation time zones are always a presentation issue, which is why you’ll find a
timeZoneproperty on NSDateFormatter. This defaults to local time but you can change it.
What you should do here depends on your specific requirements. You wrote:
I have the need to store both local time as per users timezone and UTC time in a transaction table using core data
Why store two time strings? If I were in your shoes I’d store:
The floating point absolute time offset that NSDate uses internally. You can get this via the
An integer local time offset from GMT.
From these two values you can reconstruct the date strings if you need them. And storing these values is is easier, less error prone, and more efficient than storing date strings.
Finally, if you decide to continue storing date strings, make sure you read QA1480 NSDateFormatter and Internet Dates. Your current approach will fail badly if, for example, the user toggles between the Gregorian and Buddhist calendars.
Share and Enjoy
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware
let myEmail = "eskimo" + "1" + "@apple.com"