[BUG] influx_query() does not propagate UTC when local time is different from UTC

[ckatsulis]

I currently run local time on my server 'America/Chicago'. The http query works fine and receives epoch integers referenced from a UTC origin correctly. It is when it parses the time string for conversion where the time zone origin is not forced to UTC and my local settings rebase the epoch time to my local. This isn't the case when writing to the db through influxdbr as my load processes ensures that the tz supplied to the query call is UTC.

[dleutnant]

Dealing with timezones is really a big challenge. At our institute, per DEFAULT (we've forced us to), we store all series with "GMT" zone on influx. The conversion is later performed in R. But I agree on finding a more robust solution in the R package....need to a look at it.

[ckatsulis]

I hold similar beliefs surrounding the sprawling use of UTC time, however GTC is a time zone so as unlikely as it is, it could break from an agnostic UTC standard (https://www.timeanddate.com/time/gmt-utc-time.html). The problem here isn't the data storage in UTC, but the R environment and the profile settings when as.POSIXct and striptime are evoked.

from strptime() help:

tz A character string specifying the time zone to be used for the conversion. System-specific (see as.POSIXlt), but "" is the current time zone, and "GMT" is UTC. Invalid values are most commonly treated as UTC, on some platforms with a warning.

Unless current (aka local time) is specifically set to UTC, it's going to use the current environment's default or modified settings when nothing is supplied.

As influxdb only supports UTC from my knowledge, and the json time string parse specifically looks to Zulu time, I don't foresee issues currently simply including tz="UTC" for an origin TZ reference. If at some point when influxdb supports multiple time zones, the strptime call could be changed to address this issue.