Adrian:
On Thu, Sep 12, 2019 at 4:23 PM Adrian Klaver <adrian.klaver@aklaver.com> wrote:
> > pure_seconds_interval
> > -----------------------
> > 3923:00:00
> > (1 row)
> >
> > A third representation! which gives the same result for epoch, but I'm
> > not sure it does for arithmetic....( tested it, it does not )
> >
> > I thought substraction would give me that, clearly it does not ( both
> > give the same when using epoch, as lacking tz info it has to assume
> > something, and it seems to assume no dst changes ).
>
> See doc information above. It uses the SET timezone. See below for more
> information:
I know how to set the timezone and operate with it, and Iknow for the
purpose of calculating elapsed seconds ( minutes / hours ) both
approaches are the same. What I'm saying is you must take care on how
to define and calculate your intervals if you are going to add them to
TS directly, as an 86400 seconds one has the same epoch than a 1day
one, but they represent different things when being added to a tstz,
and I know that the difference depends on the current timezone.
I do a lot of these, working with phone calls to extract ring / talk
time from setup/connect/disconnect time, and I do not hit problems
because I never do interval arithmetic on elapsed times , its not a
problem if you are aware that there are "infinite" ways to represent
an epoch in an interval .
Francisco Olarte.