Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

export time zone - customizable or similar to import #50

Open
3 tasks
MartinRaetz opened this issue Feb 19, 2024 · 2 comments
Open
3 tasks

export time zone - customizable or similar to import #50

MartinRaetz opened this issue Feb 19, 2024 · 2 comments
Labels
enhancement New feature or request

Comments

@MartinRaetz
Copy link
Contributor

MartinRaetz commented Feb 19, 2024

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
@MartinRaetz
Copy link
Contributor Author

@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 MartinRaetz added the enhancement New feature or request label Feb 19, 2024
@FWuellhorst
Copy link
Collaborator

@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 :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants