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 <emkornfi...@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 <jacq...@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
>
>>
>>
