terraform-provider-grafana
terraform-provider-grafana copied to clipboard
grafana
Support timezones for reports
Fix https://github.com/grafana/terraform-provider-grafana/blob/master/grafana/resource_report.go#L311 to support accepting a timezone (e.g. America/Los_Angeles) via the resource block.
Both the start_time and the end_time of the schedule support the RFC3339 format so you can set dates like this: start_time = "2020-01-01T00:00:00-07:00". However, it's true that it does not support daylight saving. Perhaps another attribute for timezone could be useful
Yes, that's precisely the issue. The docs rightly indicate that the time is converted to UTC and stored that way in the backend. In terms of local time, scheduled reports drift back and forth by an hour for those in DST-prone areas.
The "problem" with using named timezones is that, depending on the OS you're running, the named zone might not exist, as stated in time.LoadLocation documentation:
The time zone database needed by LoadLocation may not be present on all systems, especially non-Unix systems. LoadLocation looks in the directory or uncompressed zip file named by the ZONEINFO environment variable, if any, then looks in known installation locations on Unix systems, and finally looks in $GOROOT/lib/time/zoneinfo.zip.
Using something like time.FixedZone to define the timezone manually won't work either, as in this case the offset would need to change every time DST changes.
This means that the resulting resource definition might not be 100% portable, which might not be an issue for particular use cases but defeats the purpose of the provider as a tool to guarantee reproducibility.
I do remember facing issue loading timezones which is why I went with fixed time zones for the the initial resource
Yup. This is an issue that I've found in many different languages I used at work in the last 20+ years: PHP, C, Java, Python, Go, Ruby… all of them have the same issue with named timezones when you try to port them to other OSes.
For some reason my mind decided to forget about Perl and C# 😬 (confession time: I actually like C#)
This means that the resulting resource definition might not be 100% portable, which might not be an issue for particular use cases but defeats the purpose of the provider as a tool to guarantee reproducibility.
Yes, it might not be 100% portable. But most machines (and certainly, if you're hosting a hosting provider like Grafana Cloud) will have a tzdata. In any case, I doubt the provider guarantees reproducibility (in the sense that you can be certain that your configuration will lead to a functioning Grafana instance). Some resources are tied to Grafana Cloud, so applying against any old Grafana instance won't work. Portability != reproducibility.