CODEWITHSUNDEEP
iosswiftnstimeintervalnstimezone
AAA
AAA

Reputation: 1987

How to convert timeIntervalSinceNow in swift to a readable date

Hi I am trying to find the time interval between a certain date to the current local time. 

var a = eventDate.timeIntervalSinceNow
println(a)
//1404567.32182503 - output

When I try to do that I am getting the output as mentioned above. How can I change that in to a readable date?

I want to calculate the no.of Day, Hours, Minutes left. i dont want Years, months, Seconds.

MUST: I want the time interval between the eventdate and local time. Not the UTC time.

Here is the full code:

//eventDate is 2015-09-01 19:39 
var date = NSDate();
var dateFormatter = NSDateFormatter()
    dateFormatter.dateFormat = "YYY-MM-dd HH:mm:ss ZZZZ"
    dateFormatter.timeZone = NSTimeZone()
    var localDateString = dateFormatter.stringFromDate(date)
var localDate: NSDate = dateFormatter.dateFromString(localDateString)!

var components = NSCalendar.currentCalendar().components(.CalendarUnitSecond |
        .CalendarUnitMinute | .CalendarUnitHour | .CalendarUnitDay |
        .CalendarUnitMonth | .CalendarUnitYear, fromDate: localDate,
        toDate:  self.eventDate, options: nil)

println("\(components.day) days \(components.hour) hours \(components.minute) minutes")

16 days 5 hours 41 minutes //Origianl output
16 days 0 hours 11 minutes // Expected output

I think am facing this issue due to change in UTC time!

Upvotes: 0

Views: 5180

Answers (1)

Rob
Rob

Reputation: 438287

A couple of thoughts:

  1. If you want a string representation of the time difference (to display in UI, for example), use NSDateComponentsFormatter. For example, in Swift 3:

    let formatter = DateComponentsFormatter()
formatter.allowedUnits = [.day, .hour, .minute]
formatter.unitsStyle = .full
let string = formatter.string(from: date1, to: date2)

    or, in Swift 2:

    let formatter = NSDateComponentsFormatter()
formatter.allowedUnits = [.Day, .Hour, .Minute]
formatter.unitsStyle = .Full
let string = formatter.stringFromDate(date1, toDate: date2)

    With your example, that will show:

    16 days, 6 hours, 9 minutes

    For details on the various properties that configure the behavior of the formatter see the documentation.

  2. In your question, you show us your output:

    16 days 5 hours 41 minutes // Original output
    16 days 0 hours 11 minutes // Expected output

    You seem to be inferring from this output that there's some problem in comparing two dates. Your technique for comparing these two dates is fine (though NSDateComponentsFormatter simplifies that process, and also generates a localized string, too). But the routine for calculating the elapsed time between two dates is not the issue.

    The problem is that one of your dates (most likely the one you converted with the formatter) is just wrong.

  3. In comments, you keep asking different permutations of the same question, "how do I compare dates in my local timezone?", to which the answer is "you don't". Dates don't have time zones. Date strings do, but NSDate objects don't.

    If you perform a print of Date/NSDate objects, it will generally show them in GMT (you'll generally see +0000 after the date, confirming this fact). If you want to see them in your local time zone, use a DateFormatter and use string(from:) (or in Swift 2, NSDateFormatter and use stringFromDate()).

    But there's little point in using this stringFromDate mechanism (other purely for diagnostic purposes) to see these dates in your local timezone. There's no such thing as "difference between two NSDate objects in my local timezone". The NSDate objects indicate a single point in time around the world, and the NSTimeZone is only necessary if you want to see that point of time shown as a string representation for your local timezone.

Bottom line, the problem is not in the calculation of the elapsed time between two NSDate objects, but rather how you created those NSDate objects themselves. More than likely, the original string from parse (which you seem reluctant to share with us for some reason) is not in the time zone you think it is.

The most common mistake that people make is assuming the string is in their local time zone, whereas it invariably is in GMT/UTC/Zulu unless the date string explicitly specifies otherwise (e.g. +0530). (It's a horrible design to have a web service report dates in local timezone without timezone qualifier, so hopefully you're not doing that.)

Upvotes: 3

Related Questions