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

[Xueming Shen]

On 12/7/12 4:33 AM, Stephen Colebourne wrote:
> 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

This "idea" definitely is not specified in the spec of Query.ZONE_ID, in 
which is specified
to query for a ZoneId object from the datetime. ZoneOffset is not 
anything "implements"
ZoneId, it extends ZoneId now, which means it is a ZoneId object. Given 
current spec it
is actually a bug, if ODT/OD/OT fails to return the ZoneOffset when 
queried by ZONE_ID.

The spec of Query.ZONE_ID appears to have a type, it says "...must 
return the chronology"
now.

-Sherman



> 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
>
> ------------------------------------------------------------------------------
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> _______________________________________________
> threeten-develop mailing list
> threeten-develop at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/threeten-develop