1 day lag between MCD64A1 and FIRED in US

[pamu5248]

Corresponded with Adam Mahood about this via email (and a couple others involved in FIRED were made aware of it as well). It seems there was a known issue with a lag between daily MCD64A1 and FIRED resulting from an off-by-one indexing error (discovered when I compared the two datasets in California). Evidently this issue is/was(?) fixed; however, earlier country-level products (such as the US) may have been published prior to this bug being fixed. I believe one could remove this lag quite easily by oneself, but I'm posting this here as requested by Adam, potentially so that the dates can be corrected from the get go.

[admahood]

This is still an issue. I just checked for the one fire MCD64 found in Samoa, and day of ignition in the derived perimeter is 2011-09-25, which is the 268th day of the year, but the earliest day in MCD64 is 267. @Ckster or @maxwellCcook any way you can look into this?

[Ckster]

I'm writing some unit tests now for the burn data retrieval. I think the convertDates function may be the culprit.

date = dt.datetime(year, 1, 1) + dt.timedelta(int(julian_day))

Since the base date starts at day=1, the timedelta should be dt.timedelta(int(julian_day - 1))

Still going to test some more

[Ckster]

When I look in the version 6.1 file 'MCD64A1.A2011244.h01v10.061.2021309003958.hdf', the first ordinal day with a burn is 266. Since ordinal day 1 corresponds to the first day of the year, the correct date would be datetime(2011, 1, 1) + timedelta(days=265) which is September 23rd, or unix day 15240. The first unix day in the burn netcdf created for the whole Samoa record with the change above implemented is 15240. So I think that change fixes it.