Warum kann DateTime-Ausgabe von DateTime.ParseExact nicht analysiert werden?

Question

Während mit DateTime.ParseExact Formatierungsprobleme zu kämpfen, habe ich beschlossen, ParseExact die aus DateTime.ToString(), so sagen zu füttern:

DateTime date2 = new DateTime(1962, 1, 27); 
string[] expectedFormats = { "G", "g", "f", "F", "D", "d", "M/d/yyy", "MM/dd/yyy", "MM-dd-yyy", "MMM dd, yyy", "MMM dd yyy", "MMMM dd, yyy", "MMMM dd yyy" }; 
bool parsed = false; 

foreach (string fmt in expectedFormats) 
{ 
    try 
    { 
     DateTime dtDateTime = DateTime.ParseExact(date2.ToString(fmt), fmt, new CultureInfo("en-US")); 
     parsed = true; 
    } 
    catch (Exception) 
    { 
     parsed = false; 
    } 

    Console.WriteLine("[{0}] {1}", parsed,date2.ToString(fmt)); 
} 

Dies ist die Ausgabe:

[True] 1/27/1962 12:00:00 AM 
[True] 1/27/1962 12:00 AM 
[True] Saturday, January 27, 1962 12:00 AM 
[True] Saturday, January 27, 1962 12:00:00 AM 
[True] Saturday, January 27, 1962 
[True] 1/27/1962 
[False] 1/27/1962 
[False] 01/27/1962 
[False] 01-27-1962 
[False] Jan 27, 1962 
[False] Jan 27 1962 
[False] January 27, 1962 
[False] January 27 1962 

Was tun Ich muss tun, dass ParseExact die benutzerdefinierten Formatzeichenfolgen parsen wird? Ist es falsch zu erwarten, dass DateTime die eigene Ausgabe basierend auf derselben Formatzeichenfolge aufnehmen kann?

Answer 1

Dies zeigt deutlich, dass DateTime.ParseExact mit Datetime.ToString nicht sicher ist. Ich bin mir nicht sicher, dass dies eine große Antwort ist, aber das Problem hängt definitiv mit dem 3-stelligen Jahresformat yyy zusammen. Seit 1962 kann nicht in 3 Ziffern dargestellt werden ToString ist gezwungen, 4 Ziffern zu verwenden. Anscheinend ParseExact ist nicht intelligent genug, um diese Logik umzukehren und sucht stattdessen nach genau 3 Ziffern. Die Problemumgehung besteht darin, yyyy anstelle von yyy zu verwenden. Ich würde dies als einen Fehler auf der Microsoft Connect Website einreichen und sehen, was daraus wird.

Answer 2

Ich bin überrascht, das zu sehen, aber die Dokumentation zu Msdn sagt:

Sie können eine des Standard-Datums- und Uhrzeitformat Bezeich oder eine begrenzte Kombination der benutzerdefinierten Datums- und Zeitformatangabe angeben

http://msdn.microsoft.com/en-us/library/2h3syy57.aspx

aktualisieren

Sie können die in der vorherigen Antwort erwähnte Problemumgehung verwenden.

Answer 3

Ich nahm Ihren Code und die Änderung von "yyy" zu "yyyy" ist genug, um "TRUE" für alle zurückzugeben (nachdem ich zuerst die "FALSE" s reproduziert habe, bevor ich irgendwelche Änderungen vorgenommen habe).

Die Dokumentation in MSDN ist unklar, aber die Notwendigkeit für die Angabe über die volle Breite der einzelnen Komponenten (zB yyyy statt yyy) ohne die invariante Kultur nicht betonen:

http://msdn.microsoft.com/en-us/library/w2sa9yss.aspx

Wenn Format Ein benutzerdefiniertes Formatmuster, das keine Datums- oder Zeittrennzeichen (z. B. "yyyyMMdd HHmm") enthält, verwenden die invariante Kultur für den Provider-Parameter und die breiteste Form jedes benutzerdefinierten Formatbezeichners. Wenn Sie beispielsweise Stunden im Formatmuster angeben möchten, geben Sie anstelle der schmaleren Form "H" die breitere Form "HH" an.

Answer 4

Microsoft hat ein Zeichenfolgenformat für das Runden von DateTime implementiert. Sie verwenden das Format "o" oder "O".

Sie müssen den Formatparameter in DateTime.ParseExact auf DateTimeStyles.RoundtripKind festlegen.

Ausführliche Informationen finden Sie unter: http://msdn.microsoft.com/en-us/library/az4se3k1%28v=vs.110%29.aspx#Roundtrip