[threeten-dev] [threeten-develop] j.u.Formatter

[Stephen Colebourne]

On 7 December 2012 08:24, Xueming Shen <xueming.shen at oracle.com> wrote:
> Here is the webrev for the change of adding the support of jsr310 new
> date/time
> in j.u.Formatter.
>
> http://cr.openjdk.java.net/~sherman/jdk8_threeten/jufmt/
You have manual manipulation of ChronoField.HOUR_OF_DAY, when you should use
ChronoField.HOUR_OF_AM_PM, ChronoField.CLOCK_HOUR_OF_AM_PM and ,
ChronoField.CLOCK_HOUR_OF_DAY

> Here is the result of the Test310
> http://cr.openjdk.java.net/~sherman/jdk8_threeten/jufmt/result
>
> The current proposal/impl does not use the default timezone for Instant.
> Different compared to what j.u.Formatter does for "long" and j.u.Date.

That seems reasonable. The default time-zone is generally troublesome.

> I'm not so sure about if the "GMT" should be added to the fixed offset
> for "Z".  Any opinion?

I think we should not output "GMTZ", but we do accept it in parsing.

> Stephen, it appears the ODT/OD/OT might want to return the ZoneOffset
> when queried by Query.ZONE_ID, given ZoneOffset is a ZoneId now.

Your changes to OD/OT/ODT are certinaly questionable. The idea of the
ZONE_ID query was to return the "concept" of zone, not anything that
implements ZoneId. However, this may be too strong for users. One
option may be a new query of ZONE_OR_OFFSET which can cross-convert an
offset if it doesn't find a zone.

Note that ZDT.query(ZONE_ID) can return a ZoneOffset because that is
stored in the conceptual zone instance variable as returned by
getZone(). Whereas ODT does not have a getZone() method, thus ZONE_ID
was intended to return null.


Stephen