Weird flex date issue

Question

Flex водит меня CRAZY, и я думаю, что это странная добыча с тем, как она обрабатывает високосные годы и ни один високосный год. Итак, вот мой пример. У меня есть следующий метод dateDiff, который находит количество дней или миллисекунд между двумя датами. Если я запустил следующие три заявления, я получу некоторые странные проблемы.

 dateDiff("date", new Date(2010, 0,1), new Date(2010, 0, 31)); 
    dateDiff("date", new Date(2010, 1,1), new Date(2010, 1, 28)); 
    dateDiff("date", new Date(2010, 2,1), new Date(2010, 2, 31)); 
    dateDiff("date", new Date(2010, 3,1), new Date(2010, 3, 30)); 

Если бы вы были смотреть на даты сравнений выше можно было бы ожидать, чтобы получить 30, 27, 30, 29, как количество дней между датами. Там странно то, что я получаю 29 при сравнении с 1 марта по 31 марта. Почему? Это что-то делать с февралем, имея только 28 дней? Если у кого-то есть ЛЮБОЙ вклад в это, что было бы весьма признательно.

public static function dateDiff(datePart:String, startDate:Date, endDate:Date):Number 
    { 
     var _returnValue:Number = 0; 

     switch (datePart) { 
      case "milliseconds": 
       _returnValue = endDate.time - startDate.time; 
       break; 
      case "date": 
       // TODO: Need to figure out DST problem i.e. 23 hours at DST start, 25 at end. 
       // Math.floor causes rounding down error with DST start at dayOfYear 
       _returnValue = Math.floor(dateDiff("milliseconds", startDate, endDate)/(1000 * 60 * 60 * 24)); 
       break; 
     } 

     return _returnValue; 
    } 

Answer 1

Это не проблема високосного года, а проблема с летним временем.

Чтобы исправить код для учетной записи DST, вам нужно посмотреть на часовой поясОбновление обеих дат, чтобы определить, охватывает ли диапазон дат границу DST.

var adjustment:Number = (startDate.timezoneOffset - endDate.timezoneOffset) * 60 * 1000; 
_returnValue = endDate.time - startDate.time + adjustment; 

Это позволит получить разницу между двумя часовыми поясами (в минутах), преобразовать это значение в миллисекунды, а затем применить разницу временных зон разницы в миллисекундах, чтобы «отменить из» границы перехода на летнее время.

Естественно, что, когда оба числа находятся в одном и том же часовом поясе, значение настройки становится 0, а значения времени не регулируются.

Answer 2

У вас есть часть ответа на ваш комментарий: 2010-Mar-01 0:00 до 2010-Mar-31 0:00 тридцать дней минус один час (из 14 Мар DST начала (!) в 2010). Поскольку вы занимаете результат своего подразделения, вы получаете 29.

Редактировать: Этот ответ, конечно, основан на предположении, что свойство time Date принимает DST. Это объясняет вашу проблему; Однако я этого не проверял.