Someone stored dates as String. And they needed time too. So they stored time as String. So they wrote some more code when they converted dates from UI to back and return. So they wrote some more code when they needed different date formats.
The decision to store dates as strings in varchar fields is a case of code WTF and I cannot understand any argument for one to have done this. Date is a date and not a string. Displaying or exporting date fields for other systems to consume is a different question and the persistence model has to be independent of that. There are loads of libraries that let you deal with date conversion into various formats and that is what we should use in dealing with dates. Think how messy this will get when we do this in Canada (at least 5 commonly used date formats) or Japan (separator is a Japanese character). Overall I cannot but grimace at the idea of saving dates as strings in a database [timezone, separator, precision of minutes, seconds….]
The decision to store dates as strings in varchar fields is a case of code WTF and I cannot understand any argument for one to have done this. Date is a date and not a string. Displaying or exporting date fields for other systems to consume is a different question and the persistence model has to be independent of that. There are loads of libraries that let you deal with date conversion into various formats and that is what we should use in dealing with dates. Think how messy this will get when we do this in Canada (at least 5 commonly used date formats) or Japan (separator is a Japanese character). Overall I cannot but grimace at the idea of saving dates as strings in a database [timezone, separator, precision of minutes, seconds….]
