Timezone issue in feat info

[JonDHo]

Description

This issue is partially described (and partially resolved) in the comments of #958, but in short:

• in timezones which are behind UTC (e.g. USA, Chile, etc), the time axis in the GetCapabilities and the data_available_for_dates parameter in GetFeatureInfo responses can result in incorrect information.
• this happens due to datetimes being converted to local local timezone but then represented in OWS without timezone information, resulting in the date showing as the day before the intended date.

Steps to Reproduce

To reproduce this issue, the user must use a timezone with a negative adjustment to UTC and then:

• index example data to ODC from within a negative UTC timezone (e.g. anywhere in the Americas or the pacific ocean east of the international date line).
• add simple OWS configuration and run relevant update scripts
• inspect the GetCapabilities response and compare to the expected date
• inspect a GetFeatureInfo response (data_available_for_dates field) to compare do the expected date

In my testing, the GetCapabilities response is more "correct" than the GetFeatureInfo as explained below.

Two specific examples...

1. firstly what happens when you don't think about the timezone from the beginning and eodatasets3 adds the time component with something like p.datetime = datetime(2018,4,26):

• time listed in the generated odc-metadata.yaml for a dataset: 2018-04-26 00:00:00Z ✅ (yes, this is technically incorrect but it is a common result when not providing a specific time)
• time shown in time_view materialised view: ["2018-04-26 00:00:00+00","2018-04-26 00:00:00+00"] ✅
• time shown in time axis of GetCapabilities: 2018-04-25 ❌ (wrong but understandable given the initial 00:00:00Z)
• time shown in data_available_for_dates in GetFeatureInfo: 2018-04-25 ❌ (wrong but understandable)

2. And then if I force the initial ODC entry to something like midday to give some space for timezone adjustments:

• time listed in the odc-metadata.yaml for a dataset: 2018-04-26 12:00:00Z ✅
• time shown in time_view materialised view: ["2018-04-26 12:00:00+00","2018-04-26 12:00:00+00"] ✅
• time shown in time axis of GetCapabilities: 2018-04-26 ✅
• time shown in data_available_for_dates in GetFeatureInfo: 2018-04-25 ❌❌ (wrong - this is the biggest issue)

This issue is most obvious when adding data which has no specific time as in the first example because the timezone correction has an immediate impact. This can be partially resolved by the data administrator always thinking in UTC from the beginning and adding an adjusted time to all data in an ODC instance, but this is not always possible when indexing data from third parties (e.g. public STAC catalogs). In this case, the final error in the GetFeatureInfo response in example 2 above still causes significant issues.

[SpacemanPaul]

Worth noting that example 1 will work fine in OWS if you set the time_resolution for the layer to summary. "Summary" time resolution is explicitly for products where the timestamps are always midnight UTC.

Example 2 I believe should be have been fixed in #958 (will be in next release) but I'll take another look.

Also worth pointing out Issue #945 - which will give users another more flexible/general solution for this class of problem.

[JonDHo]

ok, thanks, I will test out summary. With Example 2, I can confirm that I am using the almost-latest datacube-ows master from a week ago (721c457). I have confirmed that the change from #958 is in my locally deployed service. That is where I am still seeing the problem in the GetFeatureInfo response being one day out.

[SpacemanPaul]

Pretty sure the remaining issues are due to a bug in the solar_day method in core. See PR referenced above.

[JonDHo]

Hi all. I have updated my datacube-ows version to the latest version on docker hub (1.8.36.post25_g20e28f8) and I can confirm that the timezone issue which I was seeing in the Americas is now fixed. This now results in the "Filter by Location" feature in TerriaMap (which feeds off data_available_for_dates) working correctly rather than being 1 day off.

Thanks for the update!