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]

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

[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

[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!

[Lars Beiderbecke]

Well, I hit an unexpected snag here: Functions RTC_DayLightSavingConfig and GetStoreOperation() are unknown to the STM32F7xx HAL. The constants are all upper-case, but that was easy to fix.

So how do F7s configure Daylight Saving? I noticed that RTC_TimeTypeDef contains a field DayLightSaving, but I'm not if this is more than information.

[waclawek.jan]

These are SPL functions. You can simply copy/paste them from 'F4 SPL (AFAIK there is no 'F7 SPL).

JW

[waclawek.jan]

/** @defgroup RTC_Group5 Daylight Saving configuration functions
 * @brief Daylight Saving configuration functions 
 *
@verbatim 
 ===============================================================================
 ##### Daylight Saving configuration functions #####
 =============================================================================== 
 
 [..] This section provide functions allowing to configure the RTC DayLight Saving.
 
@endverbatim
 * @{
 */
 
/**
 * @brief Adds or substract one hour from the current time.
 * @param RTC_DayLightSaveOperation: the value of hour adjustment. 
 * This parameter can be one of the following values:
 * @arg RTC_DayLightSaving_SUB1H: Substract one hour (winter time)
 * @arg RTC_DayLightSaving_ADD1H: Add one hour (summer time)
 * @param RTC_StoreOperation: Specifies the value to be written in the BCK bit 
 * in CR register to store the operation.
 * This parameter can be one of the following values:
 * @arg RTC_StoreOperation_Reset: BCK Bit Reset
 * @arg RTC_StoreOperation_Set: BCK Bit Set
 * @retval None
 */
void RTC_DayLightSavingConfig(uint32_t RTC_DayLightSaving, uint32_t RTC_StoreOperation)
{
 /* Check the parameters */
 assert_param(IS_RTC_DAYLIGHT_SAVING(RTC_DayLightSaving));
 assert_param(IS_RTC_STORE_OPERATION(RTC_StoreOperation));
 
 /* Disable the write protection for RTC registers */
 RTC->WPR = 0xCA;
 RTC->WPR = 0x53;
 
 /* Clear the bits to be configured */
 RTC->CR &= (uint32_t)~(RTC_CR_BCK);
 
 /* Configure the RTC_CR register */
 RTC->CR |= (uint32_t)(RTC_DayLightSaving | RTC_StoreOperation);
 
 /* Enable the write protection for RTC registers */
 RTC->WPR = 0xFF; 
}
 
/**
 * @brief Returns the RTC Day Light Saving stored operation.
 * @param None
 * @retval RTC Day Light Saving stored operation.
 * - RTC_StoreOperation_Reset
 * - RTC_StoreOperation_Set 
 */
uint32_t RTC_GetStoreOperation(void)
{
 return (RTC->CR & RTC_CR_BCK);
}
 
/**
 * @}
 */
 

 As was discussed in that thread, this only sets and reads the RTC_CR.BCK bit [edit] and RTC_CR.ADD1H/SUB1H bits[/edit].

JW

[Lars Beiderbecke]

Thanks, Jan, this is very useful.

While initially I didn't want to make use of these functions, it's actually hard to add 1 hour manually to any date and time .

[waclawek.jan]

The only reasonable way is to convert date/time to some epoch (the easiest is to use the <time.h> facilities to convert to-from UNIX epoch), perform any time shift required, and then convert back.

Note, that the logic required to subtract 1 hour, overflowing correctly to date, is missing (SUB1H bit description says, "Setting this bit has no effect when current hour is 0.").

JW