I am using Telegraf as a server to collect StatsD data from Python and send it to InfluxDB. However, the data I am getting on InfluxDB has a different timezone than mine. Where do I have to configure the timezone settings: Telegraf or InfluxDB?
Note: I will use this data with Grafana, in case I have to set something up there too.
Telegraf and influxdb are both using UTC as default timezone. As far as I know you cant set another timezone for them. What you want to do is simply use the "Local browser time" option in grafana.
Related
Wow! Tons of posts on converting GMT to local time, including correction for DST. But it seems my need is different.
As the title says, I have a stand-alone embedded system with no O/S. I'm using NTP to get UTC. That is used to tag events with an accurate date/time. I can correct UTC for the current time zone but cannot automatically adjust for DST.
Since there is no O/S, I don't have any of the Windows/Linux data such as time zone. So there is no way to locally adjust for the GMT offset.
It seems the only way for me to do this is to use an http call to find the offset, and the only way I can think of doing this is using the lon/lat or address. It would be possible for me to add lon/lat or address to the configuration so this seems like the only option.
I've seen references to sites which return the GMT offset based on location. Do these sites also automatically adjust for DST? To do that, they would have to use one of the solutions posted in many places in this forum, but that should be easy enough.
Thanks for the advice and help!
Dave
If you need to only convert a specific single timestamp to local time, then yes - you can use services such as those listed here. At least the ones offered by Microsoft and Google do convert a timestamp to the local time in the time zone given, in addition to providing the IANA time zone id.
Additionally, you'll find that the gettimezonebycoordinates function in the Microsoft Azure LBS Time Zone API returns a PosixTz value, such as "PST+8PDT,M3.2.0,M11.1.0". This is ideal for embedded systems, as you can set your TZ environment variable to this value and then many local APIs (such as with C, and others) will use this value in their conversions. This approach works best when you may be converting many different local time values and don't want to make an http call for each one.
Be aware, however, that using a POSIX time zone string has some limitations, such as being restricted to a single set of DST transition rules. They generally work ok for near-current time ranges, but not for historical purposes.
rrd files are getting generated through cron job.
I have not configured snmp and i configured the same in graph management.
So, there is no need to configure snmp on unix server (localhost).
It usually takes a while for it to collect data that it can use to generate graphs. If you set it up today, give it time for it to collate data it can use to show graphs.
The time command on the redis-cli returns the current server time (doc here). How can I change the timezone on the redis server?
Note that redis gives me UTC timezone, whereas date on the Linux terminal shows me UTC+5, which is my correct timezone (Asia/Oral).
The time command is documented as using Unix time, which is UTC, so there's no way to change that. Timezone issues are complicated, so it makes sense for the Redis server not to concern itself with them.
Instead, convert it on the client using the libraries available on your platform.
windows server has a registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation where the field ActiveTimeBias will return the offset in minutes from GMT for the machine that you are running on.
we have a web application that needs to present a user with their local time on an html page that we generate. we do this by having them set a preference for their timezone and then fetch the above value so that can compare server time and client time and do the correct calculation.
on servers that we have built this works great. we are deploying our application into a tier 1 cloud provider who is providing a windows server ami that we configure and use. what we have found is that when you use the clock control panel on a local server, the registry entrys for TimeZoneInformation are correct. when we do the same for this virtual machine, the entrys are correct with the exception of ActiveTimeBias.
Microsoft cautions against diddling the individual value in their usual fashion.
question for the community - has anyone else encountered this problem and if so, how did you fix it?
One usually doesn't program directly against these registry keys. For example, in .Net, we have the TimeZoneInfo class. It uses the same data, but in a much more developer-friendly way.
Regarding your particular question, the ActiveTimeBias key hold the current offset from UTC for the time zone that your server is set to. If your server is in a time zone that follows daylight savings rules, then this will change twice a year. If you manually update your time zone and refresh the registry, you will see it change.
The best advice I can offer is that since the timezone of the server is likely to be unimportant to anyone, you should set it to UTC.
See also: Daylight saving time and time zone best practices
Some of us are unable to store and work with time in UTC because of compatibility issues with existing data or legacy/connected systems that are purely accessed locally and non-timezone aware.
1 way is to disable saving time in UTC in rails which many have tried but not found the way to do it, I have not seen any before.
How can we override the UTC time saving in rails 3?
How do you manage such an issue in your system?
What I found to be working on my app with MSSql backend is the following combination of configs
I have in application.rb
config.time_zone = '[the server's timezone]'
config.active_record.default_timezone = :local
ActiveRecord::Base.time_zone_aware_attributes = false
time was saved as per the server time, without conversion to UTC and displayed accordingly.
I have not tried this with any other database backends.
Perhaps an alternative solution is to create dedicated time columns for use by rails and use triggers to sync between these UTC time data with another set of time columns(in local time) in order to support legacy and non-timezone aware systems.