arrow-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Micah Kornfield <>
Subject Re: [DISCUSS][Format] Time Interval Changes
Date Tue, 02 Apr 2019 03:52:35 GMT
On Mon, Apr 1, 2019 at 4:17 PM Jacques Nadeau <> wrote:

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

I could go either way, it has some benefits for forward compatibility I
suppose, but on the other hand YAGNI, if you feel strongly, I'm ok
including it.  However, the more optional fields we have for a specific
enum value, makes me lean more towards a new type instead of just an enum.

>> 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."
> 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?

The documentation, was mostly from a PR put together by Wes a while ago,
maybe he can chime in.   I think any modifications or previous statements
on my part about the proposed time being interpreted separately from a
timestamp don't make sense.  I was assuming it was OK, to ignore the few
seconds of inaccuracy that would occur with the interpretation.  I think we
would need yet another type if we wanted to measure time truly
independently of reference timestamps.    As you point out if a reference
timestamp corresponds to when a leap-second is added then
Duration/time-delta is always ambiguous.  If the reference timestamp does't
fall when a leap-second is added, it seems like the conversion is to
"actual" elapsed seconds is fairly straight-forward.

Could you elaborate on defining standard arithmetic conversions between
time-delta/duration in seconds and other time unit (days, months, years) as
part of the standard/format, I'm still not sure I understand what the
use-case is here.


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