STM32F4 RTC - Daylight Saving

[Tabulous]

I was wondering why when the rtc driver was written, why support for Daylight Saving was not added ?

As most EU counties use daylight saving, alot of people will see there RTC is now 1 hour out. I did read on another post that Giovanni, did not look at this, as it was thought to be outside the scope of the driver, but i think this was in reference to F1 devices that only have a counter.

The F4 have hardware support for clock/calandar and also Daylight Saving, thus this to me brings it back under the driver scope. Or should this be done in chrtclib.c ?


Any comments welcome

[fred]

Hi,

I looked into this a while back and from what I remember the RTC hardware on STM32F4 doesn't actually calculate whether DS should be applied or not. Instead it has 2 register bits SUB1H and ADD1H to automatically substract or add 1 hour to the RTC value when it's read.

Correct me if I'm wrong, but this means that the logic to calculate whether the current time is subject to daylight saving must be performed in the application, and then set the bit accordingly to account for it in a flexible way (i.e. not having to read and modify the RTC value).

Edit: SUB1H and ADD1H are bits 16 & 17 in RTC_CR. Explained in RM0090 on page 785.

[Tabulous]

Hi,

I looked into this a while back and from what I remember the RTC hardware on STM32F4 doesn't actually calculate whether DS should be applied or not. Instead it has 2 register bits SUB1H and ADD1H to automatically substract or add 1 hour to the RTC value when it's read.

Correct me if I'm wrong, but this means that the logic to calculate whether the current time is subject to daylight saving must be performed in the application, and then set the bit accordingly to account for it in a flexible way (i.e. not having to read and modify the RTC value).

Edit: SUB1H and ADD1H are bits 16 & 17 in RTC_CR. Explained in RM0090 on page 785.

By hardware i meant using the SUB1H / ADD1H bits, but at the moment there is nothing in the driver to allow you to set these ?

[Giovanni]

RTC will change in 3.0, please feel free to propose changes to the driver model or add requirements. Right now it is not very clear to me if do a simpler driver or a full RTC solution.

Giovanni

[steved]

The need for DST is going to depend on the application - in my world, TOD clocks are used for time stamping log entries, so consistently using UTC (or local 'standard' time) is the preferred solution. I can see that DST could be useful in other applications.

Automatically handling DST can also be tricky, since the dates on which it changes are not consistent around the world, and do not necessarily permit use of an algorithm to calculate the dates. (Some of the decisions are made by politicians - can their thought processes be modelled and predicted?)

DST support would certainly be nice to have, but not easy to support worldwide.