2009-06-27 13 views
1

Flex macht mich VERRÜCKT und ich denke, es ist ein seltsames Problem mit dem Umgang mit Schaltjahren und keinen Schaltjahren. Also hier ist mein Beispiel. Ich habe die unten dateDiff Methode, die die Anzahl der Tage oder Millisekunden zwischen zwei Daten findet. Wenn ich die folgenden drei Anweisungen ausführe, bekomme ich einige seltsame Probleme.Weird flex date issue

 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)); 

Wenn man sich die aktuellen Vergleiche sehen war über Sie 30, 27, 30, 29 wie die Anzahl der Tage zwischen den Terminen erhalten erwarten würden. Es ist komisch, dass ich 29 bekomme, wenn ich den 1. März mit dem 31. März vergleiche. Warum ist das so? Hat es etwas damit zu tun, dass der Februar nur 28 Tage hat? Wenn jemand irgendeinen Input dazu hat, würde das sehr geschätzt werden.

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; 
    } 

Antwort

4

Dies ist kein Schaltjahrproblem, sondern eher ein Sommerzeitproblem.

Um den Code für die Berücksichtigung der Sommerzeit zu korrigieren, müssen Sie den timezoneOffset-Wert beider Datumsangaben betrachten, um festzustellen, ob der Datumsbereich eine DST-Grenze überbrückt.

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

Dies wird die Differenz zwischen den beiden Zeitzonen (in Minuten) zu erhalten, um diesen Wert in Millisekunden konvertieren und dann die Zeitzone Unterschied auf die Millisekunde Differenz gilt für „aufheben“, um die DST-Grenze.

Wenn beide Zahlen in derselben Zeitzone liegen, wird der Anpassungswert natürlich 0 und die Zeitwerte werden nicht angepasst.

+0

Das ist genial !! Vielen Dank für die Veröffentlichung des Codebeispiels. Das behebt mein Problem perfekt. – CodeMonkey

0

Sie haben einen Teil der Antwort in Ihrem Kommentar: 2010-Mar-01 00.00 bis 2010-Mar-31 00.00 sind 30 Tage minus eine Stunde (weil Mar 14 DST Start (!) in 2010). Da Sie das Ergebnis Ihrer Division Boden, erhalten Sie 29.

Bearbeiten: Diese Antwort basiert natürlich auf der Annahme, dass die Zeiteigenschaft von Datum DST berücksichtigt. Dies würde dein Problem erklären; Ich habe es jedoch nicht überprüft.