tl24 / jsonexserializer

Automatically exported from code.google.com/p/jsonexserializer
1 stars 1 forks source link

Serialization/deserialization of types depends on current culture! #33

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1.
Serialize a DateTime using jsonexserializer.
2.
Change "current format" using ControlPanel => "Regional and Language 
Options"
3.
Deserialization of DateTime most probably fails.

What is the expected output? What do you see instead?

I expect deserialization to work independently of the current format 
settings.

What version of the product are you using? On what operating system?
2.1.1.144, Vista

Please provide any additional information below.

String type conversion must be done using the invariant culture, otherwise 
the serialization format itsself is not "invariant", which potentially 
breaks _every_ use of jsonexserializer for such types.

Probably only the TypeConverterAdapter needs to be adjusted to use 
invariant ConvertTo / From String methods.

This problem also exists in the alpha version 3.

Original issue reported on code.google.com by paramatrix@gmail.com on 12 Nov 2008 at 9:21

GoogleCodeExporter commented 9 years ago
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 elliott....@gmail.com on 15 Nov 2008 at 4:26

GoogleCodeExporter commented 9 years ago
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 paramatrix@gmail.com on 15 Nov 2008 at 4:46

GoogleCodeExporter commented 9 years ago

Original comment by elliott....@gmail.com on 16 Nov 2008 at 5:47

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

Original comment by elliott....@gmail.com on 26 Jan 2009 at 2:02

GoogleCodeExporter commented 9 years ago
3.0 Release

Original comment by elliott....@gmail.com on 26 Jan 2009 at 2:22