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
Is your feature request related to a problem? Please describe.
Some expect the export to be the same time zone as the import file.
This is only relevant for .mos or .epw exports.
Currently all exports are in the time zone UTC.
This is in line with the core data, which will always be converted to UTC. It is also step toward standardization and the lean option. As e.g. UTC+1, might arise the question whether it includes summer and winter time, as it might be just taken over from the import data.
Though some tools that use these weather files might not work as expected as they do not read the time zone. Additionally, it might be an unexpected result if the data is shifted. Also, if importing exactly one year in e.g. UTC+2, the export in UTC will have two hours at the end of the data set which are filled by ffill.
Describe the solution you'd like
Option 1: Keep it like is
Option 2: Always use the time zone of the import (if available)
Option 3: Give the choice to the user
Option 4: A mix of the prior.
Solution proposal
To solve this, I suggest saving (or defining) the time zone in the meta data object, which is already done in some cases, and take it from there during any core_data_2_export_file transformation. The fix should actually be simple.
Also important:
update documentation in readme and within code
update the functional tests
if applicable add custom time zone option to webapp if required
The text was updated successfully, but these errors were encountered:
@TobiasSpratte, @FWuellhorst, @LauraMaier
If any does see relevant benefits and has the time to lead this, I will volunteer to support the feature implementation.
@MartinRaetz I think the third option is the best option, as it leaves it to the users. I would favor the default being UTC, but enabling the topion of keeping the old time zone.
I agree with your points, but as the applications of AixWeather are not yet know. Maybe at some point one even needs summer- and wintertime.
The option in the export could be timezone with default utc, one option from_import and the other would be utc+x.
I already implemented this once but reverted it, as it did not influence my results. If @TobiasSpratte or @LauraMaier need this, it could also be a good first issue :)
Is your feature request related to a problem? Please describe.
Some expect the export to be the same time zone as the import file.
This is only relevant for .mos or .epw exports.
Currently all exports are in the time zone UTC.
This is in line with the core data, which will always be converted to UTC. It is also step toward standardization and the lean option. As e.g. UTC+1, might arise the question whether it includes summer and winter time, as it might be just taken over from the import data.
Though some tools that use these weather files might not work as expected as they do not read the time zone. Additionally, it might be an unexpected result if the data is shifted. Also, if importing exactly one year in e.g. UTC+2, the export in UTC will have two hours at the end of the data set which are filled by ffill.
Describe the solution you'd like
Option 1: Keep it like is
Option 2: Always use the time zone of the import (if available)
Option 3: Give the choice to the user
Option 4: A mix of the prior.
Solution proposal
To solve this, I suggest saving (or defining) the time zone in the meta data object, which is already done in some cases, and take it from there during any core_data_2_export_file transformation. The fix should actually be simple.
Also important:
The text was updated successfully, but these errors were encountered: