arbtt-stats --intervals UTC?

Create issue
Issue #27 resolved
amenthes created an issue

It appears that the --intervals flag outputs UTC rather than local timezone. This in itself isn't a problem, but it should be documented if it is intended like this.

For example, i just ran the command:

> arbtt-stats --intervals Program:firefox
Program:firefox | 08/30/15 11:54:23 | 08/30/15 12:06:23 |   13m00s
Program:firefox | 08/30/15 12:51:24 | 08/30/15 12:54:24 |    4m00s    
Program:firefox | 08/30/15 12:58:42 | 08/30/15 12:59:42 |    2m00s

my local time is 15:01 (13:01 UTC +02:00 CEST) right now, and those are the intervals from just a few minutes ago.

Again: is this intentional or could it be related to something in my setup?

Comments (8)

  1. nomeata repo owner

    Indeed, it is UTC there. I guess that is mostly laziness on my part (I will have to pass the timezone down to the relevant function), but should be no problem. I’ll look into it; as I mentioned I’m currently traveling.

  2. amenthes reporter

    If it is always UTC, i am not at all against this. In that case, it would just need a notice in the docs. What i certainly would like to avoid would be "undefinedness" as in "you get some output, but you can't tell what exactly it is".

  3. amenthes reporter

    This is what I was afraid of. Now the worst of two combinations has happened (and this is the exact opposite of what this ticket was about):

    a) it is still not documented what the expected format is (documentation has not changed). b) the format of that output changed without advance notice from UTC to local timezone.

    Additionally, there is no way to get back the old way, in case anyone depends on the specific output.

    Did anyone test what happens to the output with regard to daylight savings time? Let's say I'm running this command in december (Where I am in UTC+01:00) and want to see intervals from september (where they have been recorded in UTC+02:00) what happens now? At least with UTC (and before merging this) it was consistently UTC.

  4. Log in to comment