I just wanted to highlight an issue my team experienced while implementing an import / export function. We basically implemented the functionality using the entity object's ReadXML and WriteXML methods, with some entity flags changed to force inserts or updates accordingly.

We experienced a problem when importing entities with DateTime properties set to DateTime.MaxValue. On deserialising the DateTime objects, the time is shifted according to the local time zone. If the required timeshift is positive, this causes the date value to exceed maximum date range and deserialisation fails.

We solved this by storing all MaxValue dates as DateTime.MaxValue.AddDays(-1). This gives the timezone shift calculation some leeway without exceeding the absolute maximum. The problem manifested itself only when exporting from a timezone that is 'behind' the timezone of the destination.

I don't know if this issue should be classified as an LLBLGEN bug, DotNet bug or simply a 'feature', but I'd thought I'd offer a solution for those stuck with a similar problem

I hope you find this little anecdote helpful. Regards

http://www.xmlpitstop.com/XML/re-3585_XmlSerializer_Quiz__The_solution.aspx

colinvella wrote:

I don't know if this issue should be classified as an LLBLGEN bug, DotNet bug or simply a 'feature', but I'd thought I'd offer a solution for those stuck with a similar problem

Yes... I read and article on using DateTime that said if you do any date time work you should store UTC and local time is only used to display to/prompt from the user. I think if you did this and you were passing UTC it would eliminate this problem.

http://msdn.microsoft.com/netframework/default.aspx?pull=/library/en-us/dndotnet/html/datetimecode.asp

BOb

You can make LLBLGenPro use the xml datetime format Use the WriteXml overload which accepts an XmlFormatAspect parameter. You can then specify if you want DatesInXmlDataType