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

Wed Jan 30 08:21:21 PST 2013

Hi Stephen

There is nothing in the JDBC spec which covers Interval specifically today.  The SQL99 and above specifications are where we would look for guidance.

We had talked about adding support for Intervals in the past  in JDBC but decided to wait until 310 was finalized to revisit this.

The generic setter/getter methods would allow a vendor if they choose to support a non-mandated datatype, but it may not be portable in how they do it

We also would probably want methods on the Period classes, or elsewhere in JDBC which would be something like:

 XXXPeriod valueOf(java.lang.String val) throws java.sql.SQLException

Creates a XXXPeriod object from a String which is in JDBC year-month interval escape format
INTERVAL [ <sign> ] 'value' interval-qualifier

		• The string contains a integer value for every field that is implied by the interval-qualifier
		• If the interval-qualifer is YEAR to MONTH, the year and month fields are separated by a '-'.
		• The leading field may specify a precision which is enclosed in parentheses.
		• Only the leading field may be more than two digits long and no longer than the leading field precision
		• If the precision is not specified, it defaults to two digits
Example:
INTERVAL '100-11' YEAR(3) TO MONTH
INTERVAL '50' YEAR(4)
INTERVAL '250' MONTH(4)
INTERVAL -'100-11' YEAR(3) TO MONTH

I would need to go back and review the proposed 310 class with the JDBC EG members and gain a bit of consensus before it could be standardized.  We are just about out of runway for Java SE 8 and Intervals are something that can wait until Java SE 9 to standardize vs rush it right now.

Best
Lance

On Jan 30, 2013, at 11:08 AM, Stephen Colebourne wrote:

> 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
>> 
> 
> ------------------------------------------------------------------------------
> 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