[
https://issues.apache.org/jira/browse/GROOVY-6854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14935767#comment-14935767
]
george coller commented on GROOVY-6854:
---------------------------------------
Some observations:
SimpleDateFormat is not a threadsafe class, which is why they were
instantiating a new one at the old code on line 348.
Basically if two different threads were using JsonOutput there could be
corruption of the date data.
This highlights a problem with creating all-static method utility classes.
JsonOutput should have just been a regular class with an optional
SimpleDateFormat instance on construction. This would make it thread safe
(each thread constructs its own instance) and extensible.
I also don't understand the original author's reasoning for hiding the
writeNumber, writeDate methods since they could be useful on their own.
Since we cannot refactor JsonOutput to be a regular class the next best
suggestion I have is to include two public static fields that can be set
externally:
public static TimeZone timeZone = TimeZone.getTimeZone(DEFAULT_TIMEZONE)
public static String dateFormatString = JSON_DATE_FORMAT
Then with every call to writeDate() you'd construct a new instance of
SimpleDateFormat with those two fields.
On Tue, Sep 29, 2015 at 2:13 PM, Balachandran Sivakumar (JIRA) <
--
______________________
George Coller
geo...@coller.com
Google Chat: gcoller
Twitter: devilelephant
> JsonOutput should be configurable with ISO 8601 UTC time zone instead of GMT
> ----------------------------------------------------------------------------
>
> Key: GROOVY-6854
> URL: https://issues.apache.org/jira/browse/GROOVY-6854
> Project: Groovy
> Issue Type: Improvement
> Components: JSON
> Affects Versions: 2.3.2
> Reporter: george coller
> Labels: contrib
>
> I believe ISO 8601 prefers the use of UTC over GMT as described in
> [http://en.wikipedia.org/wiki/ISO_8601#Dates]:
> {quote}
> Time zones in ISO 8601 are represented as local time (with the location
> unspecified), as UTC, or as an offset from UTC.
> {quote}
> GMT while similar, isn't exactly UTC. For example in GMT will format a date
> as:
> {code}
> 2014-03-12T19:02:35+0000
> {code}
> instead of the arguably nicer 'Z' for UTC
> {code}
> 2014-03-12T19:02:35Z
> {code}
> Java 7 introduced the "X" flag to use instead of the "Z" flag (which is RFC
> 822, not ISO 8601) for {{SimpleDateFormat}}, which finally made the class ISO
> 8601 compatible.
> Currently our team uses this workaround for {{JsonOutput}} to get it to
> format ISO dates correctly:
> {code}
> def p = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ssXX")
> p.setTimeZone(TimeZone.getTimeZone('UTC'))
> JsonOutput.dateFormatter.set(p)
> {code}
> I believe this should be the default for JsonOutput, with some sort of
> workaround available for Groovy users who are on JDK6 or earlier.
> If using JDK8 the new date/time library classes should probably be used
> instead.
> The JsonOutput class should really be reconsidered to be a candidate for
> refactoring to a more extendable structure. The limitations of it being an
> all-static utility class are apparent with its current date handling and also
> because it doesn't clients to extend it to print their own custom classes as
> well. The current method of just dumping all properties is often too
> verbose.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
