Oggi mi sono imbattuto in un comportamento del framework che, almeno all'inizio, mi è sembrato alquanto strano...come si può capire dal titolo del post mi sto riferendo al metodo TryParse della classe DateTime e a come viene "parserizzata" la stringa in input a tale metodo, per verificare se si è in presenza o meno di una data corretta...
Dovendo verificare che la stringa contenuta in un TextBox fosse una data formattata correttamente, mi sono trovato in una strana situazione:
1 ...
2 if (DateTime.TryParse(TextBox.Text, out date))
3 ...
il valore ritornato dalla funzione era true, ma la TextBox conteneva un valore che io ritenevo, per lo meno, anomalo...ovvero "13/1" 
. Ma come? Un bug?!?!? (come al solito a pensare male...)
Altro che bug...la funzione è fin troppo intelligente 
...infatti prima di "alzare bandiera bianca" e affermare che la stringa in ingresso è tutt'altro che una data, le prova proprio tutte cercando di "ricondurre" l'input ad una data accettabile...
Nel caso in oggetto, la stringa "13/1" viene interpretata come la data "13/01/2007 00:00:00"...
...ma non solo, continuando a giochicchiarci mi sono reso conto anche dei seguenti risultati:
1 DateTime.TryParse("13/1/2", out result); // true & result = 13/01/2002 00:00:00
2 DateTime.TryParse("13/1/22", out result); // true & result = 13/01/2022 00:00:00
3 DateTime.TryParse("13/1/200", out result); // true & result = 13/01/0200 00:00:00
Bhe non ho scoperto nulla di nuovo...bastava leggere la documentazione!
This method attempts to ignore unrecognized data and parse s completely. It ignores unrecognized data if possible and fills in missing month, day, and year information with the current time. If s contains only a date and no time, this method assumes the time is 12:00 midnight. Any leading, inner, or trailing white space character in s is ignored. The date and time can be bracketed with a pair of leading and trailing NUMBER SIGN characters ('#', U+0023), and can be trailed with one or more NULL characters (U+0000).
"...sovvertiamo le gerarchie..."