Code
SmartDate dt = new SmartDate(DateTime.Now);
string SmartDateFormat = string.Format("{0}", dt);
string SmartDateToString = dt.ToString();
string SmartDateToStringNull = dt.ToString(null);
Trace.WriteLine(SmartDateFormat);
Trace.WriteLine(SmartDateToString);
Trace.WriteLine(SmartDateToStringNull);
CSLA 3.0.x Output
4/14/2008
4/14/2008
4/14/2008 10:00:00 AM
CSLA 3.5.0 OutputAs you can see, dt.Format() and dt.Format(null) produce different output, but the output is consistent from CSLA 3.0 to 3.5.
4/14/2008 10:00:00 AM
4/14/2008
4/14/2008 10:00:00 AM
The default format string didn't change.
However, SmartDate in 3.5 has much richer support for the cast operation - it can convert itself to/from quite a number of types.
Notice that your first test uses a format string, but without specifying a format. Odds are that pre-3.5 the SmartDate was converted to a string (and thus formatted), but in 3.5 I bet that string.Format() is not converting it to a string (it may be converting it to a DateTime?) and so you are seeing the difference.
SmartDate in 3.5 is a much more complete replication of DateTime than the 3.0 version - especially in terms of type conversion.
rsargent:
>> The default format string didn't change.
Sure it did.
If I have a string.Format("{0}", dt) in my code, the output will be different when I use CSLA 3.5 instead of CSLA 3.0. This is a change in the CSLA default behavior for SmartDate. This may not be a "breaking" change, but I will need to change my code to make the output the same across versions.
No, the default format string didn't change. Look at the code - you can see it is still the same.
The fact that the format string isn't used in this new scenario is not the same as saying the format string has changed...
My post wasn't denying that there was a change - I was speculating about how/why the change might have come to be - and obviously it isn't because the format string changed.
rsargent:>> Notice that your first test uses a format string, but without specifying a format. Odds are that pre-3.5 the SmartDate was converted to a string (and thus formatted), but in 3.5 I bet that string.Format() is not converting it to a string (it may be converting it to a DateTime?) and so you are seeing the difference.
The difference appears to be the implementation of IFormattable.ToString.
When I call string.Format("{0}", dt) in CSLA 3.0, the SmartDate object uses the SmartDate.ToString() method which returns SmartDate.Text.
In CSLA 3.5, IFormattable.ToString is called with a null format. SmartDate now uses SmartDate.ToString(null), which produces a different result.
To be consistent, ToString() and ToString(null) should return the same string.
That is useful information, thank you. I think this is a bug in the implementation of ToString(string). I'll change the ToString(string) overload to check for a null format string, a change you'll see in 3.5.1.
Copyright (c) Marimer LLC