Issues with time switching from CEST to CET

[M-Reimer]

I'm using your library in a light controller that I built based on an Arduino Nano. This runs 24/7 and is responsible to switch on some outdoor lighting based on some time rules and external sensors. Actually this works really well usually.

But today it, again, failed to "survive" the switch from CEST to CET. I took some time to finally find out what is going wrong here. I literally spent hours debugging my own code until I decided to have a look at the DCF library. And the reason, finally, was pretty obvious.

You use "now()" to get a timestamp. If the DST switch happens, then "now()" jumps one hour and now some of your DCF time validation routines are broken until I powercycle the whole controller.

I could fix that, but I'm asking myself if the library actually is still maintained? If you consider the library as being "unmaintained", I would continue maintaining it under the same name. I would continue with a different name otherwise.

[t-luetkenhaus]

@M-Reimer how did you fix it?
Could you please publish your changes? Thanks!

[1RandomDev]

Wouldn't this block account for an incorrect local time? It just needs to receive the DCF signal twice in a row like it does on the first startup.

Arduino-DCF77/DCF77.cpp

Lines 203 to 214 in de6ba17

	// Time can be further from internal clock for several reasons
	// We will check if lag from internal clock is consistent
	time_t shiftPrevious = (previousUpdatedTime - previousProcessingTimestamp);
	time_t shiftCurrent = (latestupdatedTime - processingTimestamp);
	time_t shiftDifference = abs(shiftCurrent-shiftPrevious);
	storePreviousTime();
	if(shiftDifference < 2*SECS_PER_MIN) {
	LogLn("time lag consistent");
	return true;
	} else {
	LogLn("time lag inconsistent");
	}

[M-Reimer]

Actually I never found the reason for my problems. I still have to reset the device once when the switch to CET happens.

I even tried to use a second Arduino to "simulate" a DCF signal to "replay" the pulses happening right at the CET time switch without a real result. So basically I've given up on this for now. It is really difficult to debug something that happens once a year.

EDIT: It could also be that some of my code conflicts with the code of the library. I REALLY want to prevent the time from ever jumping back. Time always HAS TO run in the positive direction in my case. So I want the time to basically pause when a jump back would happen.

[1RandomDev]

I'll patiently follow the debug logs next week on the 26th, if there are any issues I'll build an ESP8266 based DCF emulator that I can manipulate via a web interface for further testing. I also want to dynamically react to bit 16 which announces a pending time change 1 hour before.

[M-Reimer]

If you don't have any issues, then this Issue can probably be closed as the issue is in my code. In this case I would be very thankful for some hint on how I can prevent time from ever running backwards. The intentional "jump backwards" by one hour is not acceptable for my usecase. In this case I need my time to basically freeze until it runs in positive direction, again.

[1RandomDev]

Seems to be working flawlessly, the sync just takes a little longer as expected since we need to receive 2 undistorted DCF signals in a row. I don't see a reason why a jump backwards wouldn't be acceptable. What exactly are you trying to accomplish?