Year Change Date Problem

[scootergarrett]

This new year, I think there was an issue with the logged year not updating correctly. At midnight on Dec 29 (not even the last day of the year), it updated from Dec 29 to Dec 30 (like it should) but also increased the year from 2024 to 2025. It basically jumped to one year in the future. At the beginning of the next log file the year was corrected.
Here is a little data log snip:

General.Time,RV8803 [x32].Get Epoch,MAX17048 [x36].State Of Charge ,BME68x [x76].Humidity,BME68x [x76].TemperatureC,BME68x [x76].Pressure,BME68x [x76].Gas Resistance,BME68x [x76].Sensor Status 
...
2024-12-29T23:59:28-05:00,1735534768,118.383,35.213,20.586,97920.055,319202.000,176 
2024-12-29T23:59:43-05:00,1735534783,118.383,35.179,20.591,97919.656,319500.781,176 
2024-12-29T23:59:58-05:00,1735534798,118.383,35.113,20.593,97922.805,320400.500,176 
2025-12-30T00:00:13-05:00,1735534813,118.383,35.063,20.578,97922.469,320400.500,176 
2025-12-30T00:00:28-05:00,1735534828,118.383,34.961,20.581,97921.312,319800.125,176 
2025-12-30T00:00:43-05:00,1735534843,118.383,34.967,20.578,97920.922,320400.500,176 
...

Any ideas on what could cause this? I last updated the firmware on April 19, 2024.

[gigapod]

Hi -

That is weird...

But just now looking at the ISO8601 spec, it uses "week-based year" (this is new to me too TBH).

We're using strftime() to create the ISO8601 time string, with the %G format code for the year here.

From here

Details for %G:

writes ISO 8601 week-based year, i.e. the year that contains the specified week.
In ISO 8601 weeks begin with Monday and the first week of the year must satisfy the following requirements:

Includes January 4
Includes first Thursday of the year

If I read this correctly, when the date switched to the 30th of Dec, the ISO8601 year switched to 2025.

So this is working as it should for ISO8601 time string, but an ISO8601 time string for some end of year situations are not what one would expect.

Hope that helps.

-Kirk

[scootergarrett]

I don't think this counts as closed. you said:

but an ISO8601 time string for some end of year situations are not what one would expect

one wouldn't expect it, because its wrong. A data sample is shown as December 30 2025 that was taken 2024. its off by a year.

should the firmware be changed to have a "Y" instead of a "G"?

Just to be clear my tone is not angry.

[gigapod]

No worries - I get it. It is wrong.

From a limited search - there might be different calendar types used (which makes sense) with a week-date being one of the options. The code that was copied for the framework/data logger used the week-date (%G) format - probably b/c it listed ISO 8601 in the option.

I created this issue sparkfun/flux-sdk#180 to get this reviewed/fixed in the underlying SDK.

We looking at a late Q1 update to the datalogger firmware - once we merge in update that came through from the RP2350 port of our framework. We'll

Thanks!
-Kirk

[scootergarrett]

Neat. thanks I look forward to the update.

[gigapod]

This is now fixed - related flux issue. sparkfun/flux-sdk#180

As noted, the year date codes were incorrect - using strftime code %G, not %Y. This is fixed.

Also added support for ISO8601 "Date Week" timestamp format.

This will be in release 1.2 - out late this month.
SparkFun: Flux and DataLogger Development (view)