Serialization/deserialization of types depends on current culture!

[GoogleCodeExporter]

Serialization/deserialization of types depends on current culture!

[GoogleCodeExporter]

Dates actually have their own handler method.  In 3.0 you can actually change 
this 
handler to provide custom formats.

I'll look into a better default handling for dates.  Currently I can't think of 
a 
good sensible default for Web scenarios, since it would need to be parsed in 
the 
browser to actually turn it into a javascript Date.

I may consider writing it as an ISO string, or add a few date settings to 
control 
format and timezone handling.

Original comment by [email protected] on 15 Nov 2008 at 4:26

• Changed state: Accepted

[GoogleCodeExporter]

I see, but I would recommend to change every default string <-> type conversion 
to be 
invariant first, then looking for the consequences (don't know what JavaScript 
would 
expect, but serializing it in a JavaScript consumable format surely is a good 
thing 
:)

A lot of paranoia pops up when serialization syntax depends on user-settings. 
Culture 
settings may even affect more subtle types like doubles :(

Original comment by [email protected] on 15 Nov 2008 at 4:46

[GoogleCodeExporter]

Original comment by [email protected] on 16 Nov 2008 at 5:47

• Added labels: Milestone-Release3.0, Priority-Medium, Type-Defect

[GoogleCodeExporter]

Dates will use the InvariantCulture now and will be serialized into ISO format:
YYYY-MM-DDTHH:mm:ss.nnnnTZ

Original comment by [email protected] on 26 Jan 2009 at 2:02

• Changed state: Coded

[GoogleCodeExporter]

3.0 Release

Original comment by [email protected] on 26 Jan 2009 at 2:22

• Changed state: Verified