I'm sorry, I've been busy with several other things.
A question, what about this alternative?
enum IntervalUnit: short { YEAR_MONTH, DAY_TIME, DURATION }
table Interval {
unit: IntervalUnit;
timeUnit: TimeUnit; // defined when using duration
byteWidth: short; // defined when using duration
}
Whether this or the other, I think we should probably declare the byteWidth
of the value. Do you disagree?
Also, I don't think your definition is sufficient for a duration since it
is related to epoch time which suggests that the duration is relative to a
point in time. I think we have to declare the equivalences. Probably these:
1 century = 100 years
1 year = 12 months
1 month = 30 days
1 day = 24 hours
1 hour = 60 minutes
1 minute = 60 seconds
Otherwise, there is no consistency around how the duration maps to a
timestamp.
On Mon, Apr 1, 2019 at 10:38 AM Wes McKinney <wesmck...@gmail.com> wrote:
> I would like to propose a vote on this feature this week. Could
> someone from the Java side weigh in since there is some existing code
> relating to intervals there already?
>
> On Wed, Mar 27, 2019 at 10:49 PM Micah Kornfield <emkornfi...@gmail.com>
> wrote:
> >
> > Hi Wes,
> > Thanks for the feedback. I'm happy to update the PR to include c++ and
> python once there is consensus on the format change. I'd also welcome
> feedback and an extra set of eyes on the issues I raised below, since it is
> hard to change once we make a release.
> >
> > Based on previous discussions, I thought we were OK supporting
> YEAR_MONTH and deprecating or making DAY_TIME optional. I'm also happy to
> try to add support for these in C++/Python as a separate PR.
> >
> > I'm not sure what the "Apache Way" is on this, but it seems like this
> particular issue has taken a long time to resolve, because these threads
> tend to lose steam (even this thread only had your response over the course
> of a week). The only guidance I can find is Lazy Consensus [1], but maybe
> that doesn't apply in this situation?
> >
> > In short, it would be nice to get explicit consensus via a PMC vote or
> an alternative proposal made, that can gain consensus. I'm happy to help
> out in either case, but would like avoid this stalling out yet again.
> >
> > Thanks,
> > Micah
> >
> > [1] https://community.apache.org/committers/lazyConsensus.html
> >
> > On Wednesday, March 27, 2019, Wes McKinney <wesmck...@gmail.com> wrote:
> >>
> >> hi Micah,
> >>
> >> Sorry for the delay.
> >>
> >> I'm in favor of introducing the Duration/DurationInterval type to
> >> unblock the difference-of-timestamps / timedelta use case that many
> >> Arrow users have. I'd like Jacques or someone from the Java side to
> >> comment about this before starting a vote.
> >>
> >> We can merge these changes into a feature branch and I or someone else
> >> can complete the C++ side and work on integration tests (so we
> >> eventually have proof of two complete implementations)
> >>
> >> I'm not sure what to do with the existing YEAR_MONTH and DAY_TIME
> >> interval types. These are featured in a number of SQL database systems
> >> and so one option is to simply leave them as is.
> >>
> >> Thanks
> >> Wes
> >>
> >> On Sat, Mar 23, 2019 at 12:58 AM Micah Kornfield <emkornfi...@gmail.com>
> wrote:
> >> >
> >> > Hi arrow-dev,
> >> > I just wanted to bump this thread to see if anyone wanted to comment
> or
> >> > discuss a path forward.
> >> >
> >> > If no one chimes in by Monday evening, could I ask a PMC member to
> start a
> >> > vote on Tuesday (I believe a member of the PMC needs to initiate a
> vote?)
> >> >
> >> > I will implement the C++ side once there is consensus around the
> change to
> >> > the format.
> >> >
> >> > Thanks,
> >> > Micah
> >> >
> >> > On Tue, Mar 19, 2019 at 12:13 AM Micah Kornfield <
> emkornfi...@gmail.com>
> >> > wrote:
> >> >
> >> > > Hi Arrow Dev,
> >> > > Based on the recent thread on discussing and voting on changes to
> files
> >> > > under format, I'd figure I'd try see how the process works for
> changes to
> >> > > Schema.fbs to close out lingering time interval issues. In
> particular,
> >> > > ARROW-352 (Interval(DAY_TIME) has no unit) and ARROW-835 (Add
> Timedelta
> >> > > type to describe time intervals).
> >> > >
> >> > > I submitted a PR [1] that introduces a new DurationType that models
> >> > > (sub)seconds (excluding leap seconds) as a 8-byte integer type.
> Some of
> >> > > these issues have been discussed previously, the most recent thread
> was
> >> > > within the last month [2].
> >> > >
> >> > > The reason for creating a new type is to avoid breaking changes with
> >> > > existing types (in particular Interval[DAY_TIME] in Java). I
> think
> >> > > things worth discussing are:
> >> > >
> >> > > 1. Is this a desirable change in principle?
> >> > > 2. Naming: is DurationInterval a good name (should it be
> TimeDelta)?
> >> > > 3. New Type: Should this be collapsed as a new enum on Interval
> (because
> >> > > it excludes leap-seconds, I think it still technically falls into
> the class
> >> > > of Calendar like objects).
> >> > >
> >> > > Please feel free to add items for discussion.
> >> > >
> >> > > I'm not sure the typical time that discussions are held open for,
> but it
> >> > > would be great if we could try to get to a consensus sometime soon
> (and
> >> > > then schedule a vote). Maybe early next week is a good goal to aim
> for?
> >> > >
> >> > > Thanks,
> >> > > Micah
> >> > >
> >> > >
> >> > > [1] https://github.com/apache/arrow/pull/3644
> >> > > [2]
> >> > >
> https://lists.apache.org/thread.html/0e606a6afd2332b4ae5b4382e533bea309c790ea71c05047cf983372@%3Cdev.arrow.apache.org%3E
> >> > >
>
