I found a bug in the time series chart in perspective, which got me thinking about the way time stamping is handled in Ignition.
To start with the chart, I am feeding it data from a sql query with a t_stamp column of type datetime. Since datetime data doesn’t have any timezone data attached to it, I assumed it would be displayed verbatim in the chart. Instead the chart assumes that the raw value is in the timezone of the gateway and it needs to be converted to the timezone of the client. This is a dashboarding app with data from many different timezones, and the timestamps are always assumed to be local time from wherever the data is coming from. For example, if I am looking at data from a site in Folsom, it is assumed that if I pull in data time stamped at 12p, I know that data is from noon at Folsom. Then if I pull up a dashboard from a site in New York, I know that data at 12p, is noon in New York. This is the reason we are using datetime in SQL. Timezones should never be converted, the data should always be left alone. I was told that in a future release, the timezone conversion would respect the project timezone, so if I set the timezone to gateway timezone, it should work. My question here is this: Why is there a timezone conversion at all, when you can’t know the source timezone in the first place? The component itself really ought to ask for that info as a property.
If Ignition wants to be able to make assumptions about timezones, wouldn’t it make more sense to store time stamps as Unix time? To that point, it would be handy if transaction groups allowed storing the timestamp as Unix time, rather than having to do that manually. I know it’s an easy thing to do yourself, but it seems that IA wants Ignition to be able to tinker with timezones, so why not start pushing people to use a format that allows that to be possible?