You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently when one uses get() as explained in the readme, the query return Unix timestamps that, if converted to UTC, are outside of the request window because the get() t1 & t2 strings seem to be treated as local time.
It could be fixed if one could pass UTC timestamps for these parameters, or have at least a flag to indicate this (local or utc, ref. Timber). Working with UTC timestamps will allow users to create scripts that work in all timezones without having to hardcode their timezone. See attached files for more details.
The internal CALS Java API uses localtime timestamps. I checked with the experts and there is no way to give as input UTC, so the functionality needs to implemented at the python level. We could implement it inside pytimber...
Currently when one uses get() as explained in the readme, the query return Unix timestamps that, if converted to UTC, are outside of the request window because the get() t1 & t2 strings seem to be treated as local time.
It could be fixed if one could pass UTC timestamps for these parameters, or have at least a flag to indicate this (local or utc, ref. Timber). Working with UTC timestamps will allow users to create scripts that work in all timezones without having to hardcode their timezone. See attached files for more details.
pytimber-utc.zip
The text was updated successfully, but these errors were encountered: