2016-03-22 5 views
0

Ich habe mit einigen historischen Daten mit Ungenauigkeiten zu tun, die mein Team aufgrund der Unsicherheit in den Originaldaten nicht beheben möchte. Eines der Probleme mit falsch aufgezeichnet Daten als ungültig Parsen:Fehler mit historischen Schalttagen

> Date.parse('1876-02-29') 
=> Tue, 29 Feb 1876 

gegen

> Date.parse('1877-02-29') 
ArgumentError: invalid date 

Gibt es eine out-of-the-Box-Art und Weise die ungültigen Datum Fehler zu ignorieren, ein Date zu bekommen Objekt sowieso? Würde dies wahrscheinlich nur Validierungen in aktuellen oder zukünftigen Datenbanken verursachen? Ich lehne mich gerade darauf ab, Daten als Ganzzahlen für diese Anwendung zu behandeln.

+0

Werden diese geparst oder werden sie zurückgewiesen? Was soll es für '-290-99-48' oder' 9999-99-99' zurückgeben? Wenn Sie Probleme mit Ihren Daten haben, finde ich eine separate Spalte mit dem ursprünglichen Wert, da eine Aufzeichnung der Quelldaten eine Tonne hilft. – tadman

+0

Sie werden abgelehnt. Unser Datensatz ist eher klein (~ 6000) und wächst nicht, und wir haben keine anderen Fehlertypen, daher enthalten sie (und werden nicht) andere Fehlertypen. –

+0

Eine andere Spalte ist eine gute Idee - vielleicht ein korrigierter Wert für die Suche und eine Anzeigeversion mit einer Notiz über das Problem. –

Antwort

0

Da Sie nicht beschrieben haben, welches Datum Sie ungültige Datum Daten ersetzen möchten, sollte jedes Datum funktionieren (wenn das nicht was Sie wollten, dann wäre es Ihr Fehler das Problem nicht vollständig zu beschreiben). Wenn Sie einfach Date.new eingeben, wird ein Datumsobjekt erstellt.

require "date" 

begin 
    Date.parse('1877-02-29') 
rescue ArgumentError 
    Date.new 
end 
# => #<Date: -4712-01-01 ((0j,0s,0n),+0s,2299161j)> 
0

Verwenden Sie die Zeichenfolge Luke (oder, noch besser, mit dem Kunden sprechen)

Bad Daten schlechte Daten vorhanden sind, können die Business-Logik der Arbeit des Kunden ohne gute Daten in diesem Bereich?

Wenn ja, dann erwarte nicht einmal, dass es ein echtes Datum ist, schreibe es als String und wirf es bis zum Datum, wenn Geschäftslogik es erfordert, aber wenn es dann bricht, sind es die Daten des Clients, die repariert werden müssen - Nicht dein Code und die Tatsache, dass er kaputt gegangen ist, ist eher wie Feature als wie ein Bug.

Wenn der Client wirklich gute Daten benötigt, dann liegt es am Client, diese Daten irgendwie zu reparieren, wahrscheinlich mit Ihrer Hilfe.

Und die Frage folgt, wenn einige Daten eindeutig ungültig sind, wie viele sind falsch und scheinen nur gültig?

Nur etwas gruseliger als wenn etwas nicht funktioniert und es sollte wenn etwas funktioniert und es sollte nicht.

Verwandte Themen