Default stringy JSON format for joda.time.DateTime is "YYYY-MM-DD"

[Pathikrit Bhowmick]

Copied from here: https://github.com/playframework/playframework/issues/4844

Although joda.time.DateTime can have precision information of hours, minutes, seconds etc the only acceptable default JSON formats for it in play-json are unix timestamps (longs) and YYYY-MM-DD. See these lines of code which make it impossible to specify minutes/hours etc in a string-based format. 
This bad pattern probably came from the method itself being incorrectly named here - it should be def jodaDateTimeReads instead of def jodaDateReads since it returns Reads[joda.time.DateTime] and notReads[joda.time.Date]

Reads[joda.time.DateTime]s should use the ISODateTimeFormat.dateTimeParser instead of specifying an explicit pattern. This strategy was correctly used for Reads[joda.time.LocalDate] which correctly falls back to the ISODateTimeFormat.localDateParser when an explicit pattern is not specified.

I understand, I can always create my own implicit and use it but it makes things harder when I am relying on external macro libraries like metarest or this which rely on the default Readers

[Dale Wijnand]

I also feel this pain. I'm hoping that this can be a breaking change with Play 3.0. Perhaps if 3.0 is Java 8+ then it could provide Reads/Writes for java.time that return ISO-8601 format.

Dale

[Greg Methvin]

This seems odd to me as well. For the default implementation I'd expect it to parse using something similar to DateTime.parse(str). That would allow ISO 8601 dates with optional time strings.

It'd also be nice to change the default Writes to use strings, but that'll have to wait for 3.0.

[Pathikrit Bhowmick]

How do we track the progress/ownership/priority of this bug?

The issue I filed on GitHub (https://github.com/playframework/playframework/issues/4844) was closed but the bug remains.

[Claudio]

On Monday, July 13, 2015 at 9:39:23 PM UTC+2, Dale Wijnand wrote:

I also feel this pain. I'm hoping that this can be a breaking change with Play 3.0. Perhaps if 3.0 is Java 8+ then it could provide Reads/Writes for java.time that return ISO-8601 format.

Play 2.4.x already depends on Java 8 (see Java 8 support). And there already are default Reads/Writes for java.time._ types. So you could migrate from Joda-Time to JSR-310 today.

But, currently at least the implementation in 2.4.2 for java.time.Instant Reads/Writes is buggy and I'm trying to get this fixed. So, maybe you want to join the discussion here: https://groups.google.com/forum/#!topic/play-framework/VFMTGPCW7Hc

-- 

Claudio

[Greg Methvin]

Adding the dev list.

I would definitely consider this a bug. If we're going to parse strings, we should parse full ISO-8601 strings, and perhaps abbreviated versions as well. I propose we change this to a behavior similar to DateTime.parse, since this parses plain dates as well as full datetime strings, so it's mostly backwards compatible with the current implementation.

We should consider migrating to the JSR-310 types internally in Play 3.0 and recommending using java.time._ types in the documentation. It seems like the Reads/Writes implementations we have for those are pretty reasonable. We just need to make sure we add support for those types in other parts of the APIs

I would also prefer the default DateTime writes to write a string (ISO-8610 date) rather than a number, but I'm concerned that change could break a lot of people's code. What do people think about changing this in 3.0? Ultimately we should make the reads/writes for the Joda types line up with their JSR-310 counterparts as much as possible.

--
You received this message because you are subscribed to a topic in the Google Groups "play-framework" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/play-framework/vofrDXZqpTI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to play-framewor...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/play-framework/4418b94a-e805-4e72-839a-3136620099ea%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Dave Stevens]

This has been a problem for me for a long time as well. 

My suggestion for the best way to move forward with this would be to make the Reads[DateTime]/Writes[DateTime] definitions included in play-json non-implicit.

See also https://groups.google.com/forum/#!searchin/play-framework/joda/play-framework/060q6Qp0TeU/2i_i9vY1pwcJ 

[Pathikrit Bhowmick]

Agree with Greg.

In Play-3.0:

Drop support for joda in play-json from the main repo. Add it as a separate library for those who need it.

Fully support JSR-310 in play-json. Default formatters for both reads and writes should ISO-8601s for any Temporals. 

[Jean Helou]

+1

You received this message because you are subscribed to the Google Groups "Play framework dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framework-...@googlegroups.com.