Daylight Saving: The Details?

[Lars Beiderbecke]

This is a spiritual followup to this post: https://community.st.com/s/question/0D50X00009XkYuH/rtc-daylight-saving-time-stm32f3-discovery

So I do get which functions to use for daylight saving, and how to BCK bit remembers if I already changed to DST or not.

But:

1. Since I have to call either function manually, how do I compute "second Sunday in March" or "last Sunday in March"? If I check the date every (running) minute, how can I count Sundays (in particular if the board was powered off during the first Sunday)? Do I need to revert to time() etc.?
2. Wouldn't frequent checks drain performance? Is there no better way, e.g., by using callbacks? Should I set alerts for the DST dates?
3. If the BCK bit has to be set again after each boot, how do I know if it should be set of not? By comparing the current date against the DST dates? But then I could power down the board just before DST start, and power on again after it. Then the BCK bit would be set, but the time would not have been adjusted, which is wrong.

Calling daylight saving functions seems easy enough, but how to implement this efficiently? Note that the F7 HAL libraries don't include daylight savings examples.

[Uwe Bonnes]

Use UTC and there is no problem ;)

[Lars Beiderbecke]

True, but I need to display date and time, so UTC would irritate people.

[Uwe Bonnes · Accepted solution]

Still run the clock in UTC and corrected to the best effort before displaying.

[Lars Beiderbecke]

I like that idea a lot. But problem (1) would still remain: How to figure out the dates of start and end of DST without re-implementing a calendar? Or isn't that too hard? Is time.h available?

[waclawek.jan]

> spiritual followup to this post

That thread merely states that the "library" functions provide only a thin skin on regular register access (i.e. there's no benefit in using them - as is the case with most of the "libraries").

> how do I compute "second Sunday in March"

That's the Sunday between 8.3. and 14.3. inclusive. Similarly "last Sunday" etc.

You can perform this check when you need the date/time, for example, if it's less often than doing it periodically. Or you can use the Alarm facilities of the RTC. There are many ways to skin a cat. How to approach this depends on your application.

> If the BCK bit has to be set again after each boot

What is "boot"?

RTC_CR thus RTC_CR.BCK won't be cleared unless backup domain is cleared, and that means also the current time loss. Read the RTC chapter and relevant portions of PWR and RCC chapters in RM.

JW

[Uwe Bonnes]

Start and end of Daylight saving is a political process, so there is no formula. In Europe, an educated guess is last sunday in March and october for switching, until perhaps parliament cancels daylight saving. Linux and probaly all other systems get updated in some file to cope with this problems. If you plan updates for your system do something similar. If not, only an educated guess is possible.

[Lars Beiderbecke]

Yes, of course, and I gave two examples. So how do I compute those examples? How do I compute "the second Sunday in March" for, say, the year 2025?

[Lars Beiderbecke]

> That thread merely states that the "library" functions provide only a thin skin on regular register access (i.e. there's no benefit in using them - as is the case with most of the "libraries").

Fine. But I prefer HAL functions to register mashing.

>> how do I compute "second Sunday in March"

> That's the Sunday between 8.3. and 14.3. inclusive. Similarly "last Sunday" etc.

Yes, obviously. I need a date, though, and that mechanism should work for 2034 as well. But yes, you could pre-compute these for a couple of years.

>You can perform this check when you need the date/time, for example, if it's less often than doing it periodically. Or you can use the Alarm facilities of the RTC. There are many ways to skin a cat. How to approach this depends on your application.

OK, makes sense.

>> If the BCK bit has to be set again after each boot

>What is "boot"?

You're right, I meant power off and power on.

>RTC_CR thus RTC_CR.BCK won't be cleared unless backup domain is cleared, and that means also the current time loss. Read the RTC chapter and relevant portions of PWR and RCC chapters in RM.

I was talking about power loss, including removal or failure of battery. IIRC that kills the backup domain. Storing on the file system is also no option, since the SD card might be swapped ...

[Lars Beiderbecke]

To summarize all suggestions,

• I precompute a table of DST dates for the US and Europe, and store that. If the table depletes, I prepare an update.
• I keep the RTC in local "winter" time, and don't use the DST HAL functions.
• Whenever I need a time, I compute the DST offset (0 or 1), based on the DST dates.
• The actual time is then local winter time + offset.

That should cover it.

Thanks for your help!