Re: [threeten-develop] Instant should implement DateTime
Status: Alpha
Brought to you by:
scolebourne
From: Roger R. <Rog...@or...> - 2012-08-23 19:52:09
|
Stephen, this may have gotten lost in your inbox. Please take a look at the branch and integrate. If there are issues please let me know. Roger On 8/9/2012 7:41 AM, Roger Riggs wrote: > I would keep Instant as a simple point in time but accessible via > DateTime > with EPOCH_DAY, and NANO_OF_DAY, NANO_OF_SECOND fields plus > extract(ZoneOffset) > returning a UTC offset so it is precisely defined at runtime. > > There is no field EPOCH_SECOND which is prominent in the methods of > Instant. > Might be worth considering. > > See https://github.com/RogerRiggs/threeten branch 'instant-rr' for > the spec, impl and a couple of tests. > > Roger > > > On 8/7/2012 6:49 PM, Stephen Colebourne wrote: >> On 7 August 2012 18:40, roger riggs<rog...@or...> wrote: >>> Some of the conversions would be simpler and more consistent if Instant >>> could be treated as supporting the EPOCH_DAY and EPOCH_SECOND fields. >>> There isn't enough precision to support nanoseconds so some conversions >>> to time might be loose the nanoseconds. >>> A reasonable alternative would be to supporting only EPOCH_DAY. >> If Instant implemented DateTime (or AdjustableDateTime) then it could >> support the full range of fields using the UTC conversion to a local >> date/time. Or it could, as you suggest, support a subset. >> >>> Am I missing something subtle? >> One point is with the definition of UTC vs local time. EPOCH_DAY is >> actually LOCAL_EPOCH_DAY, and the same with EPOCH_SECOND, something >> that is quite subtle in the API right now. (This BTW might argue for >> two separate fields for these concepts, or for ODT to take into >> account the offset). >> >> The real issue with Instant is one of intent. The class is intended to >> be a simple point in time, a time-stamp that should only really be >> used to record the instant and compare it earlier/later than another >> one. However, us humans still tend to want to print it out, which >> causes problems. >> >> Thus the underlying question is whether Instant should become just the >> UTC version of ODT, or therefore potentially removed entirely. For me, >> I find modelling with Instant useful because it gets people to >> separate the storage of a totally neutral instant in time from the >> representation given to it by humans. >> >> Perhaps implementing DateTIme would be OK though, it just feels like >> the thin end of the wedge, >> >> Stephen >> >> ------------------------------------------------------------------------------ >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats.http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> _______________________________________________ >> threeten-develop mailing list >> thr...@li... >> https://lists.sourceforge.net/lists/listinfo/threeten-develop > > -- > Thanks, Roger > > Oracle Java Platform Group > > Green Oracle <http://www.oracle.com/commitment> Oracle is committed to > developing practices and products that help protect the environment > -- Thanks, Roger Oracle Java Platform Group Green Oracle <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment |