UFL Timezone Conversion
Supported timestamps are currently limited to Local or UTC timezones.
Data sources may not be configurable to provide timestamps in supported formats.
There currently exists no robust or simple way of converting between timezones using the UFL syntax or configuration. Including custom daylight savings time logic in ini files for this is not a maintainable solution. DST rules change over time and vary from region to region.
With the current limitations I am currently having to maintain more than 20 ini files with custom DST logic for our global operations.
Including functionality to accommodate for the timezone formatting limitations of data sources would be appreciated.
Jake Messner
shared this idea
4 comments
-
Devin
commented
Just wanted to ping this thread again. It's over 2 years since this issue was raised. 2 YEARS!!!!! Dealing with DST is basic functionality critical to this connector being practical.
-
gheorghe.vatui
commented
In a nutshell, we would need access to Windows' timezone table to pick and choose timezones at runtime. That is, when PI UFL reads a file, from the file header or name it infers which time zone data in the file is in, then it looks up the timezone (one lookup per file). Once it finds the timezone, it goes on reading all data lines from the file, parsing timestamps in the timezone found. Then, when sending to PI it could convert to UTC and send as UTC timestamps (/utc flag). That functionality would be great
-
gheorghe.vatui
commented
I believe UFL could take advantage of .NET and it's time conversion capabilities. I am not sure if one can parse a string in whatever time zone you need in .NET, but for sure we can parse a string as UTC and convert back to the time zone needed. All this is using Windows timezone registry info which is normally up-to-date and fairly complete (covers history as well)
-
messingerj
commented
This would be a useful feature, though I'm not sure how it would be implemented. We're working with a customer to process files generated in 2-3 different US based timezones, but importing the data into a PI server in Australian Eastern Standard timezone.