Daylight Savings Timing Issue

[Punkster81]

Recently on the 3rd almost all of our devices started spamming messages:

time_t now = Time.now();



 if (!nextDaily || nextDaily <= now)
        {
            LocalTimeConvert conv;
            conv.withCurrentTime().convert();

            conv.nextDayMidnight();
            newDay = true;
            nextDaily = conv.time;
        }

 if (isNewDay())
    {
        publish(true, "New Day", "%d", Time.day());
    }

Here is the code were using to determine if its a new day or not. Were using the LocalTimeRK Library, not sure if you would know anything about this @rickkas7

The spamming started around 10 pm on the 3rd and ended around 10 pm on the 4th. Were suspecting something with DST had to do with this and what the fix could possibly be

[rickkas7]

What are you using for your timezone configuration string?

Are you using Time.zone()? You cannot use that at the same time as LocalTimeRK as they will conflict with each other.

[Punkster81]

LocalTime::instance().withConfig(LocalTimePosixTimezone("EST5EDT,M3.2.0/2:00:00,M11.1.0/2:00:00"));

from an example you gave me a while ago

Problem with using Time.day() to trigger something once a day

Theres a really similar post that says the solution to by problem accept for it does not seem to be working for me void updateTime() { if (newSec) { newSec = false; } else if (Time.second() != secondTracker && Particle.syncTimeDone()) { secondTracker = Time.second(); newSec = true; } if (newMin) { newMin = false; } else if (Time.minute() != minuteTracker && Particle.…

And I'm not using Time.zone() any where. I believe it should just be relying on the library for all time based triggers

[gusgonnet]

@Punkster81

        publish(true, "New Day", "%d", Time.day());

Hi, can I suggest you comment out this line while things are sorted out?
You'll be using your data ops.

Disregard if you already have.

[Punkster81]

That is a great Idea, just to clarify though the spamming did stop at around 10pm (EST/DST )on the 4th, it normally operates as you'd expect, once a day at midnight (GMT).

[Punkster81]

@rickkas7 Sorry if you are investigating it currently but did you have an follow up on what this possibly could've been?

[rickkas7]

Yes, it's a bug, but I don't have a fix yet. The problem is that nextDayMidnight() increments the seconds by 86400 if the day rolled backwards after adjusting for local time midnight, but on a DST fall back, that's not enough to advance to the next day, so it returns the same day each time it's called.

[Punkster81]

Ok thank you for the update, please let us know if you get a fix working!

[rickkas7]

0.1.3 (2024-11-06)

• Fixed a bug where nextDayMidnight(), nextDay(), and nextTimeList() could return the same day on daylight saving fall back because the day has more than 86400 seconds. Now does a calendar date calculation instead of relying on a specific number of seconds in a day.

• Also a similar problem for prevDay().

[emcdee]

Rick I just want to say thank you, much appreciate all your diligence / support, from one huge Particle enthusiast to another.