[threeten-dev] [threeten-develop] Hypothetical Period/Duration change

[Lance Andersen - Oracle]

It is too late for JDBC 4.2 to make any additional changes for INTERVAL given how late we are in the Java SE 8 schedule.  


INTERVAL in SQL is defined as:

year-month Intervals
date-time Intervals


Now not all vendors support Intervals and not all follow the SQL Standard exactly

Here is a pointer to the Oracle docs http://docs.oracle.com/cd/B19306_01/server.102/b14200/sql_elements003.htm


Thought has to be given as to how these would map for example with DatePeriod and it including days and I have not looked to see if there are any issues with SQL Interval precision as of yet

On Jan 30, 2013, at 10:35 AM, Stephen Colebourne wrote:

> On 30 January 2013 15:25, Roger Riggs <Roger.Riggs at oracle.com> wrote:
>> The mapping of SQL INTERVAL requires a mapping to a Java type;
>> currently Period fills that function.  INTERVAL never mixes years and
>> months
>> with days and time.  (Douglas pointed this out in email from 12/7/2012
>> "Period")
>> 
>> If we have two types, the mapping map be difficult for developers to
>> manage
>> though Douglas may be able to see a way.
> 
> My understanding is that this change would be beneficial to SQL/JDBC.
> 
> Their YEAR/MONTH concept would map to DatePeriod.
> Their DAY-TIME concept would map to TimePeriod.
> 
> This change is dependent on JDBC agreeing to this.
> 
>> We might take on the restriction from SQL that Period cannot be used
>> simultaneously
>> used for both purposes. Adding the restriction to Period could be simpler,
>> and Duration removed.
> 
> Having two classes is not the problem here. Having two classes where
> it is unclear as to the purpose of each class is.
> 
> Restricting the state of the current Period class in weird ways that
> are difficult to describe is not something I find appealing.
> 
>> It would not provide the compile time type difference between machine time
>> and human time.  But the difference in behavior and semantics comes
>> from the type the duration/period is applied to.
>> Instant, LocalDate, LocalTime, OffsetTime, OffsetDateTime all treat Period
>> as
>> a Duration.  Only ZonedDateTime has any ability to deal with the TZ data
>> variances and that could be addressed with different methods on ZDT to
>> handle the two cases, adding machine time vs adding human time.
> 
> This is sort of correct, but Duration cannot hold year or month.
> 
> We've arrived at the TemporalAmount interface, and I think we should
> stick with that now. It will scale OK with two implementations. Having
> two methods to do different things is less flexible than using the
> interface.
> 
> Stephen
> 
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_jan
> _______________________________________________
> threeten-develop mailing list
> threeten-develop at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/threeten-develop

-------------- next part --------------

Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com