Comments (19)
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
from nodatime.
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
from nodatime.
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
from nodatime.
Original comment by jonathan.skeet
on 17 Mar 2012 at 9:21
- Added labels: V1-OutOfScope
from nodatime.
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
from nodatime.
Original comment by malcolm.rowe
on 13 Jul 2012 at 8:33
- Added labels: Type-Enhancement
from nodatime.
Original comment by malcolm.rowe
on 14 Jul 2012 at 8:54
- Changed state: Accepted
from nodatime.
Original comment by malcolm.rowe
on 30 Jul 2012 at 7:47
- Added labels: Milestone-1.1-consider
- Removed labels: V1-OutOfScope
from nodatime.
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
from nodatime.
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
from nodatime.
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
from nodatime.
Original comment by malcolm.rowe
on 25 Jan 2013 at 8:29
- Added labels: Milestone-1.2-consider
- Removed labels: Milestone-1.1-consider
from nodatime.
Original comment by malcolm.rowe
on 25 Jan 2013 at 8:30
- Added labels: Milestone-1.2.0
- Removed labels: Milestone-1.2-consider
from nodatime.
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
from nodatime.
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
from nodatime.
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
from nodatime.
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
from nodatime.
All types now implemented, including PeriodBuilder.
Original comment by jonathan.skeet
on 18 Apr 2013 at 8:20
from nodatime.
All documented.
Original comment by jonathan.skeet
on 26 Jul 2013 at 6:33
- Changed state: Fixed
from nodatime.
Related Issues (20)
- Does `SkippedTimeException` use the right base constructor? HOT 2
- Typo in comment HOT 1
- Custom Pattern Support for text serialization HOT 6
- Nullable arguments in Parse methods HOT 1
- Incorrect names for Ukrainian aliases HOT 2
- Idea: Add the ability to compute `Interval` compliments HOT 9
- Question: FakeClock and AutoAdvance HOT 3
- Use Int128 in .NET 8 target
- Check AOT support in .NET 8
- Repository link in nuget is point to website HOT 2
- Proposal: Week type HOT 2
- Conversion operators `Duration` - `TimeSpan` HOT 2
- Period Between invalid calculation HOT 5
- NodaTime 3.x makes app flagged as Malware HOT 7
- Remove polyfil package HOT 1
- Missing timezone for Kosovo HOT 2
- Provide RFC9557 patterns HOT 5
- Calling Instant.FromUtc(2024, 2, 29, 12, 0) results in a out of range exception HOT 3
- Potential mistake in the docs for `LocalDatePattern.CreateWithInvariantCulture` HOT 4
- Consider adding Period.{Max,Min}Value HOT 14
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from nodatime.