Describe the bug
The dates currently included in CSV filenames represent the API request boundaries rather than the first and last observation dates requested by the user. For example, the current file name may contain dates that do not align with the date range selected in the app. There are already TODO comments in the source code related to this behavior (https://github.com/CUAHSI/SWOT-Data-Viewer/blob/develop/frontend/src/_helpers/hydroCron.js).
HydroCron is currently not directly connected to the date range selected by users. In our current code, the end date is computed as the current date plus seven days. This offset seems to be related to cache duration, although I'm unsure if it is needed at all. Cache duration should be handled independently from the user's requested time range. This should not cause the dates displayed in the filename to differ from the date range selected by users.
To Reproduce
Steps to reproduce the behavior:
- Go to (https://swotviz.cuahsi.io)
- Click on a river
- Create a plot for a date range of interest
- Download the data.
- Compare the dates in the filename with the dates used when creating the plot.
Expected behavior
Dates in the filenames should correspond to user's requested start and end dates rather than API/cache request boundaries.
<featureType>_<name>_<id>_<requestedStartDate>_<requestedEndDate>.csv
The API/cache implementation may continue to use whatever boundaries are necessary internally, but those details should not be reflected in the filename.
Remove/update the relevant TODO comments for this behavior.
Describe the bug
The dates currently included in CSV filenames represent the API request boundaries rather than the first and last observation dates requested by the user. For example, the current file name may contain dates that do not align with the date range selected in the app. There are already TODO comments in the source code related to this behavior (https://github.com/CUAHSI/SWOT-Data-Viewer/blob/develop/frontend/src/_helpers/hydroCron.js).
HydroCron is currently not directly connected to the date range selected by users. In our current code, the end date is computed as the current date plus seven days. This offset seems to be related to cache duration, although I'm unsure if it is needed at all. Cache duration should be handled independently from the user's requested time range. This should not cause the dates displayed in the filename to differ from the date range selected by users.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
Dates in the filenames should correspond to user's requested start and end dates rather than API/cache request boundaries.
<featureType>_<name>_<id>_<requestedStartDate>_<requestedEndDate>.csvThe API/cache implementation may continue to use whatever boundaries are necessary internally, but those details should not be reflected in the filename.
Remove/update the relevant TODO comments for this behavior.