Problem with SmartDate

Problem with SmartDate

Old forum URL: forums.lhotka.net/forums/t/7321.aspx


Frazer posted on Wednesday, July 22, 2009

We have an application which includes a SmartDate property (VehicleEarliestNextVisitDate) and, as suggested, uses a string property for setting:

Public Property VehicleEarliestNextVisitDateString() As String

Get

Return GetPropertyConvert(Of SmartDate, String)(VehicleEarliestNextVisitDateProperty)

End Get

Set(ByVal value As String)

SetPropertyConvert(VehicleEarliestNextVisitDateProperty, value)

End Set

End Property

When we test this in our development environment, it works just fine. We can see that our code is providing values in the form "mm/dd/yyyy" eg>  "06/20/2009"

When we deploy the application to another machine, the date value is being provided in the same format (mm/dd/yyyy) but we get a System.ArgumentException: String value can not be converted to a date.

We suspect there is some kind of default date format issue at the heart of this, but we are quite baffled.  Is there some interaction between SmartDate and system configuration which might result in this behaviour?  Can anyone suggest another possible cause?

 

 

 

ajj3085 replied on Wednesday, July 22, 2009

Is the other machine using the same culture settings? For example, is it set to format dates in UK style format instead of US?

Frazer replied on Wednesday, July 22, 2009

I am assuming since our business object assemblies are being use in a web app, that the culture settings for the web app would apply.

The culture is set to Invariant Language (Invariant Country)  in both instances.  

ajj3085 replied on Thursday, July 23, 2009

I'm not sure, but I think asp.net might try to get the culture from the browser and set its context accordingly. This has nothing to do with the culture set for your assembly.

Frazer replied on Thursday, July 23, 2009

This may well be the case.

In any event, I have worked around the issue by using Date.TryParse to parse the date string into a date and then setting the value directly,using SetProperty instead of SetPropertyConvert.  Since TryParse will return Date.MinValue when the value is not a valid date, this works for our requirements.

I still would like to understand why SetPropertyConvert has an issue with this (be it a culture mismatch or otherwise).

Frazer

 

RockfordLhotka replied on Thursday, July 23, 2009

You could step through the code in the debugger to see which coercion technique is failing.

SetPropertyConvert() calls CoerceValue(), which tries every technique I'm aware of in .NET for coercing a value from one type to another, one after another. Once of the techniques must be trying to do the conversion and flat out failing (actually two of them, because all the easy technqiues are wrapped in a try..catch block, so the really expensive final resort technique only occurs as a final resort.

Frazer replied on Thursday, July 23, 2009

In fact, I have been trying to do this.  Our problem is that I cannot seem to replicate the root cause in our development environment and I am not able to step-debug on the production machine.  

Our exception logging shows that the StringToDate method, called from the Text property setter in SmartDate, is throwing.

In the development environment, I can emulate the exception, by modifying the date string value (i.e. switching the order of month and day), just before the coercion.

I deployed a patched version of our code to our production machine to get some info into the log.  In the logged message, I captured the value of "value" and it is a date string in the format mm/dd/yyyy  (eg: 02/27/2009).

This is exactly the same format we see in our development environment - but some setting that is different between the two systems causes StringToDate to fail on on, and not the other.

It is also curious that the workaround with Date.TryParse works - although this is a less than desirable solution.

RockfordLhotka replied on Thursday, July 23, 2009

If I recall correctly, SmartDate uses TryParse() to convert the date – or maybe it uses Parse().

 

But CoerceValue() will use System.Convert in some cases, so maybe that’s what happens?

 

Without unit test illustrating the problem there’s little I can do to help change the framework to address it.

 

Rocky

ajj3085 replied on Friday, July 24, 2009

Are you logging the thread's CurrentCulture and CurrentUICulture values?

I keep supsecting this because of documentation on DateTime: http://msdn.microsoft.com/en-us/library/ch92fbc1.aspx

Notice this paragraph "Because the DateTime..::.TryParse(String, DateTime%) method tries to parse the string representation of a date and time using the formatting rules of the current culture, trying to parse a particular string across different cultures can either fail or return different results. If a specific date and time format will be parsed across different locales, use the DateTime..::.TryParse(String, IFormatProvider, DateTimeStyles, DateTime%) method or one of the overloads of the TryParseExact method and provide a format specifier."

Copyright (c) Marimer LLC