Adrian: On Thu, Sep 12, 2019 at 4:23 PM Adrian Klaver <adrian.klaver@xxxxxxxxxxx> 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.
