XML serialization should be supported about nodatime

[GoogleCodeExporter]

Sorry for not seeing this before - my email settings weren't appropriate.

Serialization is a tricky one as it ties us to a particular format. Now Instant 
isn't too bad, as I can't see that changing in the future - but I don't want to 
tie anything else down for v1. Do you think it's useful to have just a very few 
types serializable for v1? With a custom serialization format (particularly for 
XML) we could probably manage LocalDate, LocalTime, LocalDateTime, 
ZonedDateTime and Instant... although ZonedDateTime is relatively tricky due to 
zone ID stability.

Original comment by jonathan.skeet on 7 Feb 2012 at 8:04

[GoogleCodeExporter]

Instant is all I need. But indeed it's subtle, because there's XML, JSON and 
other friends, and they each have their own formats. We really just like using 
it for timestamps, and then on the .NET side we can turn it into other objects 
for proper calculations. At the moment we've gone back to using DateTime (and 
calling the fields XxxUtc hand hoping for the best from our programmers) since 
it serializes consistently.

Original comment by [email protected] on 7 Feb 2012 at 8:51

[GoogleCodeExporter]

I'd really like to make a start on this *without* it blocking V1, but equally I 
don't want to saddle V1 with serialization which ends up being changed.

I propose we start a new branch for serialization, regularly merge changes from 
mainline into that branch, and concentrate on *just* supporting what you 
(Sebastian) need for the moment. This is possibly best discussed on the mailing 
list, if that would be okay - but am I right in saying that 
DataContractSerializer + Instant would be sufficient for now?

I don't know anything about DataContractSerializer at the moment, but I think 
I'd want any text representation to represent the UTC/ISO textual 
representation - does that sound reasonable?

Original comment by jonathan.skeet on 12 Feb 2012 at 12:52

[GoogleCodeExporter]

Original comment by jonathan.skeet on 17 Mar 2012 at 9:21

• Added labels: V1-OutOfScope

[GoogleCodeExporter]

Once we finish the NodaTime.Serialization.JsonNet implementation, we can do 
similar things for other serializers, like 
NodaTime.Serialization.DataContractSerializer etc.

Original comment by mj1856 on 17 Mar 2012 at 9:40

[GoogleCodeExporter]

Original comment by malcolm.rowe on 13 Jul 2012 at 8:33

• Added labels: Type-Enhancement

[GoogleCodeExporter]

Original comment by malcolm.rowe on 14 Jul 2012 at 8:54

• Changed state: Accepted

[GoogleCodeExporter]

Original comment by malcolm.rowe on 30 Jul 2012 at 7:47

• Added labels: Milestone-1.1-consider
• Removed labels: V1-OutOfScope

[GoogleCodeExporter]

I too need XML serialisation of NodaTime types.  

I've been looking at this and it appears that Jon's approach of separate 
serialisation assemblies will not work with System.Xml!

De/Serialisation is performed by using attributes and/or interfaces attached to 
the type. This means we need to add the IXmlSerialisable interface and methods 
to the type in its base assembly not in a separate assembly for serialisation 
to XML.

I've used Reflector and have not found anyway of configuring System.Xml to 
accept other types as a simple (primitive) type for XML serialisation.  This 
also means that NodaTime types cannot be serialised as XML attributes!

Original comment by makaretu on 8 Oct 2012 at 7:42

[GoogleCodeExporter]

No, I'm not surprised that XML serialization won't work for Noda Time at the 
moment. I think it's reasonable to try to add it at some point, but it should 
definitely be post-v1. At that point we'll have a definitely-stable 
representation, I'd hope...

Original comment by [email protected] on 8 Oct 2012 at 9:25

[GoogleCodeExporter]

See some discussion and patch here: 
https://groups.google.com/d/topic/noda-time/Va4tue6bh0U/discussion

Original comment by malcolm.rowe on 30 Oct 2012 at 8:43

[GoogleCodeExporter]

Original comment by malcolm.rowe on 25 Jan 2013 at 8:29

• Added labels: Milestone-1.2-consider
• Removed labels: Milestone-1.1-consider

[GoogleCodeExporter]

Original comment by malcolm.rowe on 25 Jan 2013 at 8:30

• Added labels: Milestone-1.2.0
• Removed labels: Milestone-1.2-consider

[GoogleCodeExporter]

There are three big issues here:

- As makaretu says, we won't be able to serialize Noda Time types as 
attributes. Boo!
- IXmlSerializable requires public parameterless constructors and mutable 
types. For our value types, that *may* not actually be as bad as it sounds, 
although it will need some testing. Basically, we'd need to use "this = ... " 
in ReadXml, which is really bizarre. It means we can't serialize a DateTimeZone 
or CalendarSystem though. That's probably okay, as normally we'd want to 
serialize values instead
- We can't easily configure a time zone provider. I think we'll need a global 
variable for this, which is horrible :(

Original comment by jonathan.skeet on 11 Apr 2013 at 8:45

[GoogleCodeExporter]

One further downside: any code referring to any serializable types (i.e. 
anything using Noda Time basically) will need a reference to System.Xml.dll, 
just because the types implement the interface. Given that the DLL will be 
present at execution time anyway, it shouldn't be an issue in terms of binary 
compatibility... and I'd expect 99.9% of projects to have a reference to 
System.Xml anyway... but it could theoretically give a backwards compatibility 
boundary in terms of building.

Original comment by jonathan.skeet on 12 Apr 2013 at 7:59

[GoogleCodeExporter]

Initial commit for this (on a new branch): revision b12c78b2b783.

Types I think we want to support for serialization:
- Instant
- Offset
- Duration
- OffsetDateTime (done in the above commit)
- LocalDateTime
- LocalDate
- LocalTime
- ZonedDateTime
- Interval

All of those should be fine, as they're all structs. But I suspect it would be 
good to serialize Period as well... and that's trickier, unless we make it 
mutable :(

Original comment by jonathan.skeet on 14 Apr 2013 at 7:38

[GoogleCodeExporter]

Now done Instant, OffsetDateTime, LocalDateTime, LocalDate, LocalTime and 
ZonedDateTime.

That leaves Offset, Duration and Interval, all of which should be fairly 
simple. Then there's documentation (including the horrible static property to 
determine the IDateTimeZoneProvider to use for ZonedDateTime).

Original comment by jonathan.skeet on 17 Apr 2013 at 9:49

[GoogleCodeExporter]

All types now implemented, including PeriodBuilder.

Original comment by jonathan.skeet on 18 Apr 2013 at 8:20

[GoogleCodeExporter]

All documented.

Original comment by jonathan.skeet on 26 Jul 2013 at 6:33

• Changed state: Fixed