0

I need to convert a string date in the following format and while the date is returning correctly the time is not. The string being sent is "2022-08-16 02:07:11 America/Los_Angeles" however I'm getting back 2022-08-16 09:07:11 +0000. Can't understand why when the timezone is right and I'm also missing the America/Los_Angeles despite using VV in the formatter. How can I get the right format back?

I also thought this maybe a console print bug??

var stringToDate: Date {
        let dateFormatter = DateFormatter()
        dateFormatter.locale     = Locale(identifier: "en_US_POSIX")
        dateFormatter.calendar   = Calendar(identifier: .gregorian)
        var calendar             = Calendar(identifier: .gregorian)
        calendar.timeZone        = TimeZone(identifier: "America/Los_Angeles")!
        dateFormatter.timeZone   = TimeZone(identifier: "America/Los_Angeles")
        dateFormatter.dateFormat = "yyyy-MM-dd HH:mm:ss VV"
        let date = dateFormatter.date(from: self)
        return date!
    }
Warve
  • 481
  • 1
  • 8
  • 22
  • [This is just how `Date`s are printed.](https://stackoverflow.com/q/39937019/5133585) If you want them printed in a different timezone, convert them to a string using a `DateFormatter` with `timeZone` set to your desired time zone. – Sweeper Aug 16 '22 at 11:55
  • @Sweeper Haha - so let me get this right, I have a string that I need to convert it to a date and the only way to know it's worked is to convert it back to a string??? – Warve Aug 16 '22 at 11:57
  • What do you mean by "know it's worked"? You don't need the timezone information to "know it's worked" because the timezone information is not part of a `Date`. As I said in my [answer to your previous question](https://stackoverflow.com/a/73360100/5133585), "2022-08-14 20:45:39 +0000" represents the *same instant* as "2022-08-14 13:45:39 America/Los_Angeles", therefore it has worked. `Date`s represents *instants* in time. – Sweeper Aug 16 '22 at 12:01
  • @Sweeper - I need to know the conversion is correct as I'm using the date to figure out whether an account has expired (you know, simple stuff). `02:07:11 America/Los_Angeles` doesn't equal `09:07:11 +0000` as per my question as it's 7 hours ahead not 9 hours behind, which it should be – Warve Aug 16 '22 at 12:05
  • Where did you get "9 hours behind" from? [LA is 7 hours behind UTC in the summer](https://www.timeanddate.com/time/zone/usa/los-angeles), so when UTC is 09:07:11, LA is 02:07:11. Makes sense? – Sweeper Aug 16 '22 at 12:09
  • @Sweeper - Ahhh so time is always UTC on device unless corrected, but not on print()? – Warve Aug 16 '22 at 12:12
  • Let us [continue this discussion in chat](https://chat.stackoverflow.com/rooms/247305/discussion-between-sweeper-and-warve). – Sweeper Aug 16 '22 at 12:15
  • 1
    @Warve **"A Date value encapsulate a single point in time, independent of any particular calendrical system or time zone. Date values represent a time interval relative to an absolute reference date."** In other words if you get the date now anywhere in the world it will store the number of seconds since January 1st 2001 UTC (also know as reference date). This point in time is the same amount of seconds regardless where you are located in the world. Only its description will vary. If you need to check your date you can use `date.description(with: .current)` or a specific locale. – Leo Dabus Aug 16 '22 at 13:00
  • 1
    @Warve check this [post](https://stackoverflow.com/a/28016692/2303865). This will help you understand a bit more about date and its des Lipton as well as how to avoid creating multiples date formatters. – Leo Dabus Aug 16 '22 at 13:04
  • @LeoDabus Thanks for your help and understanding on this. Turns out the issue was related to the data being converted. Managed to solve it by enforcing Epoch time throughout the pipeline. All the dates/times now match irregardless of locale. – Warve Aug 16 '22 at 17:41
  • @Sweeper - Same as above (couldn't notify two at once) – Warve Aug 16 '22 at 17:41

0 Answers0