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

[Stephen Colebourne]

Lance, can you provide the sections of the JDBC spec that are
affected? It would be useful to be able to determine if we would
actually be breaking your spec.

Stephen


On 30 January 2013 16:02, Lance Andersen - Oracle
<Lance.Andersen at oracle.com> wrote:
>
> 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
>
>
>
> 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
>
>
> ------------------------------------------------------------------------------
> 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
>