Как преобразовать timeIntervalSinceNow в быстром для читаемой даты

Question

Привет Я пытаюсь найти временной интервал между определенной датой и текущим местным временем.

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

Когда я пытаюсь сделать это, я получаю вывод, как указано выше. Как я могу изменить это на удобочитаемую дату?

Я хочу рассчитать день, часы, минуты слева. Я не хочу Годы, месяцы, секунды.

ДОЛЖЕН: Я хочу временной интервал между eventdate и местным временем. Не время UTC.

Вот полный код:

//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 

Я думаю, что я перед этой проблемой в связи с изменением времени UTC!

Answer 1

Пара мыслей:

1. Если вы хотите строковое представление разницы во времени (для отображения в пользовательском интерфейсе, например), используйте NSDateComponentsFormatter. Например, в Swift 3:

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

   или, в Swift 2:

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

   С вашим примером, который будет показывать:

   16 дней, 6 часов, 9 минут

   Подробнее о различных свойствах, которые настраивают поведение форматирования, см. the documentation.

2. В вашем вопросе, вы показать нам свой вывод:

   16 дней 5 часов 41 минут // Оригинальный выход
   16 дней 0 часов 11 минут // Ожидаемый выход

   You похоже, выводят из этого вывода, что есть некоторые проблемы при сравнении двух дат. Ваша методика сравнения этих двух дат прекрасна (хотя NSDateComponentsFormatter упрощает этот процесс, а также генерирует локализованную строку). Но процедура расчета истекшего времени между двумя датами не является проблемой.

   Проблема в том, что одна из ваших дат (скорее всего, одна из тех, что вы преобразовали с помощью форматирования) - это просто неправильно.

3. В комментариях вы продолжаете задавать разные перестановки одного и того же вопроса: «Как сравнить даты в моем локальном часовом поясе?», На который ответ «вы не делаете». Даты не имеют часовых поясов. Строки даты делают, но NSDate объектов нет.

   Если выполнить print из Date/NSDate объектов, она будет показывать их в GMT (вы обычно видите +0000 после даты, подтверждающие этот факт).Если вы хотите увидеть их в своем местном часовом поясе, используйте DateFormatter и используйте string(from:) (или в Swift 2, NSDateFormatter и используйте stringFromDate()).

   Но есть мало смысла в использовании этого механизма stringFromDate (другого для диагностических целей), чтобы увидеть эти даты в вашем местном часовом поясе. Нет такой вещи, как «разница между двумя объектами NSDate в моем локальном часовом поясе». Объекты NSDate указывают на единую точку во времени по всему миру, и NSTimeZone необходим, только если вы хотите увидеть этот момент времени, показанный в виде строкового представления для вашего местного часового пояса.

Нижняя линия, проблема заключается не в расчете истекшего времени между двумя NSDate объектами, а то, как вы создали те NSDate сами объекты. Скорее всего, исходная строка из синтаксического анализа (которая, по вашему мнению, неохотно делится с нами по какой-то причине) не находится в часовом поясе, который вы так считаете.

Самая распространенная ошибка, которую люди делают, предполагает, что строка находится в их локальном часовом поясе, тогда как она неизменно находится в GMT/UTC/Zulu, если строка даты явно не указывает иначе (например, +0530). (Это ужасный дизайн, чтобы иметь отчет о датах веб-службы в локальном часовом поясе без квалификатора часового пояса, поэтому, надеюсь, вы этого не делаете.)