It's a pity that .NET doesn't make a distinction between "data strings" and "display strings". I mean, instead of ToString() you'd have ToDataString() which returns a culture-independent string of data, and ToDisplayString() which returns a culture-dependent
string used for display purposes.
In my own code, I've created some static classes with extension methods to convert values (int, long, DateTime, ...) to data strings and back. You can then write code like this:
DateTime d = DateTime.Today;
string s = d.ToDataString(); // s will be "2009-12-29"
d = s.ToDateTime();
It also knows about nullable values, so you can use s.ToDateTimeOrNull() or convert nullable DateTime to data string.
You can find the code on CodePlex (in folder TC/src/TC.Core in the files ConvertXXX.cs).
Tommy it can get even worse than that.....
if you make a web service that passes a datetime to a client (or client to server) if the client and server are in different timezones the date and time will not be right!
the soap dattime is just a date and time string with no timezone info.
and .net make the date a "local" timezone based date.
in some stuff i do i have to pass the datetime as a string to avoid some issues with that.
i also have an app that has to convert date and time across timezones and has to show 2 date-time values for a given event.
one is always eastern US time and the other can be anywhere... when i first set that up i had folks telling me it was wrong cuse they did not understand the nutty rules that some locales have for when to add or subtract time from UTC / zero.