ZonedDateTime seconds since midnight

[me21]

How do I get ZonedDateTime instance seconds since midnight properly?
I currently use zdt.localDateTime().localTime().toSeconds(), but I think it will return incorrect result if the time zone daylight saving changes on this day.
Consider Europe/London timezone on Sunday, 31 March, 2024, 3:00 AM. The DST kicked in on that day at 1:00 AM, moving the clock 1 hour forward. So, at 3:00 AM the midnight was 2 hours ago.

[me21]

Currently I came up with the following code:

ace_time::acetime_t secondsSinceMidnight(const ace_time::ZonedDateTime& zdt) {
  auto midnight = zdt;
  midnight.hour(0);
  midnight.minute(0);
  midnight.second(0);
  midnight.normalize();
  return zdt.toEpochSeconds() - midnight.toEpochSeconds();
}

[bxparks]

There are timezones where "midnight" does not exist on certain days. What is the expected behavior of the code in that case? What are you really trying to calculate?

[me21]

Good point. Can I find a list of them somewhere?
I use the number of seconds since midnight as part of the generated file name. The files are continuously generated during the operation of my firmware.

[bxparks]

There is no explicit list that I am aware of. The info is theoretically all encoded in the TZDB files, and it is possible write code to generate such a list of timezones and dates where midnight does not exist. Not hard, but not trivial either. The situation happens primarily due to a timezone switching to DST exactly at midnight, i.e. 00:00 goes to 01:00. Although there exists at least one timezone that I am aware of where they skipped an entire day, going from Dec 29 to Dec 31st if I recall.

For timestamped filenames, why use the local time? Isn't UTC more appropriate, so that you never have to worry about DST changes?

[me21]

UTC is less convenient for visual search in the file list. I mean, the user might want to read a file corresponding to some event which is probably dated in his timezone. I'll think about it, though.

[bxparks]

That's true. But with local time, you will have duplicate timestamps (when DST ends), and non-existing timestamps (when DST starts). That seems far worse.

[me21]

That's true. But with local time, you will have duplicate timestamps (when DST ends), and non-existing timestamps (when DST starts). That seems far worse.

That's why I thought about calculating the number of seconds from midnight with DST 🙂 then there would be no duplicates, but it's possible to have 90000 seconds in a day. Non existent timestamps are lesser problem.

[bxparks]

Non-existent timestamps are a problem because "midnight" may not exist. :-)

What does your filename pattern look like?

[me21]

{Device_name}_{date}_{seconds_since_midnight}.csv

[bxparks]

How many of these CSV files will be generated per day?
Another problem that I see is converting that format back to UTC timestamp.

How about using both UTC and local time, like:
{device_name}_{UTC_datetime}_{short_local_datetime}.csv

For example:
mydevice_UTC20240814T172902_Local0814T102902.csv

[bxparks]

Moving to Discussions, since this isn't a bug with AceTime.

[doanerock]

Why not save the files in UTC but display the file in the UI as the persons local time zone.