arrow-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Micah Kornfield <emkornfi...@gmail.com>
Subject Re: [DISCUSS][Format] Time Interval Changes
Date Mon, 01 Apr 2019 19:04:56 GMT
Sorry sent this too early.
TL;DR;  I'm in favor of moving forward with this declaration:
table Interval {
  unit: IntervalUnit;
  timeUnit: TimeUnit; // defined when using duration
}

I don't think we should include byte-width unless we have a concrete
use-case (it can be added later, using 8 Bytes as the default if not set).

Comment below on equivalences, is that I don't fully understand this.
Defining the new type as a difference between two Unix Epochs seems
sufficient, and consumers can provide there own rules of thumb.  If we want
to model explicit DAY, MONTH, YEAR, etc objects, I think we should have a
type that enumerates those fields explicitly.

On Mon, Apr 1, 2019 at 12:01 PM Micah Kornfield <emkornfield@gmail.com>
wrote:

> TL;DR;  I'm in favor of moving forward with this declaration:
>
>
> On Mon, Apr 1, 2019 at 11:38 AM Jacques Nadeau <jacques@apache.org> wrote:
>
>> 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
>> }
>>
> I would lean towards this, and rename Duration to TimeDelta (I think
> Duration might be confusing, especially given the questions below.
>
>
>>
>> Whether this or the other, I think we should probably declare the
>> byteWidth
>> of the value. Do you disagree?
>>
>
> I disagree, unless we want to support multiple byteWidths for
> Duration/TimeDelta (and i would rather add this in later while choosing a
> default of 8 bytes for it).
>
>
>>
>> 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.
>>
> I think my use of Duration might have added confusion here.  Could you
> elaborate what you are proposing?  I think the  I feel uncomfortable doing
> this conversion in the absence of a timestamp (if implementations want to
> make these approximations that seems fine, but I don't think it should be
> part of the standard), the fact that this is
>
>>
>>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message