Time Shift When Importing IMERG HDF5 Data to DSS Format

[Prabin8169]

I'm currently working on a HEC-RAS model and using gridded precipitation data from NASA Earthdata (IMERG, in HDF5 format). I'm experiencing a time shift issue when importing this data into DSS format using the HEC-DSS Importer (Vortex).

Problem

I downloaded IMERG HDF5 files for the date range May 8, 2025 to May 15, 2025. The HDF5 filenames and internal timestamps correctly indicate this time window. However, after importing into a DSS file, the time window appears shifted in HEC-DSSVue to May 21, 2025 to May 28, 2025.

To work around this, I used the Time Shift Tool in HEC-DSSVue to manually correct the timestamps, and the data then worked correctly in HEC-RAS. However, I’m trying to understand the root cause of this shift.

Questions

1. Is this a known issue with how HDF5 timestamps (particularly from IMERG data) are interpreted during the DSS import process?
2. Should simulation windows and boundary conditions in HEC-RAS be adjusted to match the shifted DSS time range?
3. Or is it recommended to continue using the DSSVue Time Shift Tool as a standard workaround?

Additional Notes

• I've verified the timestamps inside the original HDF5 files — they correctly reflect the date range and match the filenames.
• The discrepancy appears to occur during or after the import process.
• I’ve attached an example screenshots (with filename date May 8, 2025), but in the resulting DSS file, the data begins on May 21, 2025.

I think it would be a great addition if this can get fixed.

Thanks,
Prabin8169

[tombrauer]

@Prabin8169 I've noticed this issue with the GPM IMERG data as well. I thought I had traced it back to the data source and the HDF5 files but maybe I'm mistaken. I've worked around by time-shifting via the Vortex time-shifter utility in my past couple of encounters. I'll take a closer look at the data to try to figure out what is going on.

[tombrauer]

@Prabin8169 this should be addressed in v0.11.29. The data source provided dates according to a julian calendar but gregorian was assumed. Now julian should appropriately be accounted for.

[Prabin8169]

@Prabin8169 this should be addressed in v0.11.29. The data source provided dates according to a julian calendar but gregorian was assumed. Now julian should appropriately be accounted for.

That makes sense. Thank you so much.