How to make the Arduino and RTC work with the Daylight saving time?

Hi,

I am using Arduino to control light conditions for a project. The precision of time is very critical and I use the RTC in the code. The clock did not switch to daylight saving time this weekend, but the computer clock did. I re-started the computer just in case but it didn't fix the issue. And I do not understand why. Shouldn't it synchronize with the computer? I read different posts about time adjustements but I don't know why the pc and arduino are not synchronized. And I don't have time to make some tests after code modifications as I need it to work correctly for the project. I am in the Pacific Time zone and here is the code I use

#include <Wire.h>
#include <Chronodot.h>
#include <Time.h>
#include <TimeAlarms.h>

Chronodot RTC;

time_t syncProvider()
{
return RTC.now().unixtime();
}

void setup()
{
Serial.begin(9600);
Serial.println("Initializing Chronodot.");
Wire.begin();
RTC.begin();
setSyncProvider(syncProvider);

if (! RTC.isrunning()) {
Serial.println("RTC is NOT running!"); // following line sets the RTC to the date & time this sketch was compiled

RTC.adjust(DateTime(2014,3,10,5,59,0));

}

if(timeStatus()!= timeSet)
Serial.println("Unable to sync with the RTC");
else
Serial.println("RTC has set the system time");

Alarm.alarmRepeat(6,0,0, MorningAlarm);
Alarm.alarmRepeat(18,0,0, EveningAlarm);
}

void loop(){
digitalClockDisplay();
Alarm.delay(1000);
int irLed = 9;
int redLed = 10;
analogWrite(irLed, 100);
analogWrite(redLed, 8);

}

void MorningAlarm(){

int whiteLed = 11;
analogWrite(whiteLed, 150);

delay(1000);

Serial.println("LIGHT ON");
}

void EveningAlarm(){

int whiteLed = 11;
analogWrite(whiteLed, 0);

delay(1000);

Serial.println("LIGHT OFF");
}

void digitalClockDisplay()
{
DateTime now = RTC.now();

Serial.print(now.year(), DEC);
Serial.print('/');
if(now.month() < 10) Serial.print("0");
Serial.print(now.month(), DEC);
Serial.print('/');
if(now.day() < 10) Serial.print("0");
Serial.print(now.day(), DEC);
Serial.print(' ');
if(now.hour() < 10) Serial.print("0");
Serial.print(now.hour(), DEC);
Serial.print(':');
if(now.minute() < 10) Serial.print("0");
Serial.print(now.minute(), DEC);
Serial.print(':');
if(now.second() < 10) Serial.print("0");
Serial.print(now.second(), DEC);
Serial.println();

delay(5000);

} // END

I am not very familiar with Arduino yet, I just started to use it a few weeks ago. Any explaination/suggestion? Thanks for your help,

Audrey

Don't forget Code Tags.

What RTC are you using? Its possible it doesn't account for daylight savings time. Or, since the US decided to be annoying about it, it accounts for it next weekend.

Hi Mirith,

Sorry for the code tags.
I use the ChronoDot V2.1 High Precision RTC.
Sorry for what might be a stupid question, but I am new to Arduino: as this clock could be used anywhere on earth and therefore needs to be set in the adequate time zone, shouldn't it just synchronize with the pc? Or is it working on another principle? Anyway in the worst case, I can still just take that into account myself when I set the time for the alarms, but I would like to understand how it works.
Is there a way to know if it will account for the daylight saving time next weekend? Which would be the worst option, as "uncontrolled"..

Thanks,

Audrey

Hi Audrey,

Potentially you could write some code in your sketch to change to DST & back again at the appropriate dates & times. Use a byte of EEPROM to store the current DST status so it doesn't get done more than once.

Also, here is a suggestion for simplifying your sketch a little:

void digitalClockDisplay()         
{
  DateTime now = RTC.now();
  char buffer[20];
  
  sprintf(buffer, "%02d/%02d/%02d %02d:%02d:%02d", now.year(), now.month(), now.day(), now.hour(), now.minute(), now.second());
  Serial.println(buffer);
   
  delay(5000);
   
}

Paul

Hi Audrey,
Check out this library by my friend Jack.

It has all the functions you are looking for. Jack also has libraries for several of the RTC chips used with the arduino on GIT.
Duckie

Hi Paul and Duckie,

Thanks for the suggestions, I will try with that.

Audrey

OP,

I am not sure where you live. Most the world does NOT use "day-light-saving" time. If you live in the USA, not all states use it either. Tell me that a small micro-controller such as Arduino is able to determine where it is located and what local rules is and adjusts to this rule. Having a USB cable to a computer is no help. I have a bunch of flash drives. They don't update time when DST goes into effect.

The most effective way is just to program it into arduino code to do the adjustment, and hope you are not running timed events based on RTC tick. They will be screwed, say if you run something every 2 hours. You have to account for that too.

All my projects in deployment are using the UTC. They upload data to servers, which determines the local time from the UTC time stamp and the time zone parameter each unit has.

liudr:
All my projects in deployment are using the UTC. They upload data to servers, which determines the local time from the UTC time stamp and the time zone parameter each unit has.

Kinda like Linux, eh?

AudreyM:
shouldn't it just synchronize with the pc? Or is it working on another principle?

Your RTC will automatically synchronize with the PC only if you've coded both the Arduino and your PC to do so. There's nothing in your code that does that. It tests to see if the RTC is running, and if not, sets it to a specified date and time. You could code your project to query an attached computer for the time, but you'd also have to have some software on the computer to recognize and respond to that query (IIRC, one of the RTC examples has sample code for Processing to do that). But there's no automatic updating going on.

Paul__B:

liudr:
All my projects in deployment are using the UTC. They upload data to servers, which determines the local time from the UTC time stamp and the time zone parameter each unit has.

Kinda like Linux, eh?

We wouldnt even have this problem if we dont have to use dst, some useless concept anyway. Have you guys used it once or twice in the past?

Makes a difference up north during the winter months.
Kids catching the school bus appreciate it.
I don't though.

LarryD:
Makes a difference up north during the winter months.
Kids catching the school bus appreciate it.
I don't though.

How north are you? Further north than I am? With DST winter days kind end around 4pm here. It's dark at 4pm. It's also dark at 8am. The days are just shorter. There is no way to adjust that away.

Canada
Rather than 8:57 sun rises at 7:57 kids take advantage of the morning light not the evening.

That's a bit further north. DST helps a bit with the morning.

Audrey,

If there is an RTC out there that comprehends and adjusts for DST, I'm not aware of it.

RTCs are usually meant to be capable of standalone operation and do not in themselves have the ability to sync with a PC or anything else. That would be a job for firmware (i.e. your code) in the microcontroller (Arduino).

This library as mentioned above is one way to do it. It assumes the RTC is set to UTC and then adjusts to the proper local time. It's been around now through several DST changes so is working well AFAIK.

HTH ... jc

AudreyM,
One key thing to remember, and liudr mentioned, you don't want to adjust the actual time.
It is much better to always keep the actual time in UTC.
So what you want to do is modify the way the time is presented to the user when it is shown
for human consumption. This is a concept that people often overlook.
Modifying the actual time can have bad consequences especially if using timestamps.
Also, if using UTC time tracking, the actual time is not ever modified when changing timezones
or DST adjustment.
The only thing that is changed is the broken down time when it is presented to the user.
So tracking time in UTC is a much better way to track time.
Jacks', timezone library, fudges up the UTC time_t value to create an equivalent local time time_t value
that has been adjusted for DST rules.
While messing with time_t values is normally something that is not done, the benefit of it is that it allows
using the existing time library (which doesn't understand localtime)
to break down the modified time_t value into a local time for human consumption.
If using the time_t values for logging, never use the modified time_t values from the timezone library,
always use the UTC time_t value which is the actual time.

--- bill

bperrybap:
It is much better to always keep the actual time in UTC.

Yes, consider: During the standard-to-daylight time transition, there is one hour in local time that does not exist. During the daylight-to-standard time transition, there is one hour in local time that occurs twice. UTC can always be converted to local time, but local time cannot always be converted back to UTC unambiguously.

Indeed the whole DST concept is pretty dumb. Hurts my head to think about it

Indeed, DST is one of the most idiotic ideas around. Believe it or not, at the rather large university where I used to work, they keep two sets of clocks. Thousands of them! It was "easier" for the custodians to hang different clocks, than to go around and reset the time on each one. Imagine the expense!

The only moderately rational argument I've every heard in favor of DST is so that school children don't have to go to school in the dark AM hours. Wouldn't it be easier for everyone if the schools just started later during that period?