> > > > 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). > I'm okay with only allowing one today. I wonder whether we should declare it now and only allow 8?
> > Comment below on equivalences, is that I don't fully understand this. > I don't either :) "Unix time numbers are repeated in the second immediately following a positive leap second. The Unix time number 915148800.50 is thus ambiguous: it can refer either to the instant in the middle of the leap second, or to the instant one second later, half a second after midnight UTC." https://en.wikipedia.org/wiki/Unix_time#Leap_seconds If that's the case, what does the comment in the format mean exactly when you say "unix time excluding leap seconds"? I don't really understand what a duration has to do with unix time but my understanding is unix time also respects leap seconds typically which means what? I think that a duration has to be understood in its relationship to addition to a timestamp to be meaningful across systems, doesn't it? > 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 > > > >> > >> >
