bxparks
ZonedDateTime seconds since midnight
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.
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();
}
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?
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.
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?
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.
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 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.
Non-existent timestamps are a problem because "midnight" may not exist. :-)
What does your filename pattern look like?
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