Two missed daily sends and a day of month two days behind point at the report's date source, not a broken clock. Read the panel clock, the PLC clock and one forced test report inside the same minute, then correct only the value the test report matches, or the report logic in the project if both clocks are already right.
A daily report email arrives with the correct time and the correct year, but the day of month is two days behind, right after two sends failed to go out. That pattern points at the place the report gets its date. The fastest way to pin it down is one comparison pass: read the panel clock, read the PLC clock, force one test send, and see which value the fresh report matches. The sections below give the symptom list, the pass, the arithmetic that rules drift out, and the fix for each outcome.
Why is the day of the month in my emailed report two days off?
The day of month lags by exactly the count of missed sends, 2 days here, while time of day and year stay correct. That points at a date source that only moves when a report goes out. Compare clocks before you change anything.
The matching count is the clue, and the readings around it narrow the cause. Work down this list and stop at the row that matches your emails:
- Correct time of day and year, day of month behind by exactly the missed-send count: the printed date comes from a value tied to the send history. Run the comparison pass below before you touch any clock.
- Time of day losing minutes over weeks: real-time-clock crystal drift, roughly 1.7 seconds per day at a standard crystal tolerance. A different fault, and far too small to move a date by two days.
- Whole timestamp shifted by one hour, time included: a daylight saving setting mismatch. Tick the daylight saving box in the panel's time settings for your location.
- Wrong day only in the inbox's date column, right date inside the report body: the mail system can set the shown date at upload when the message carries no timestamp of its own. The fault sits in the mail path, and no clock is wrong.
Which clock does the report actually read?
The symptom does not name its source. Open the project file for the panel family concerned, which carries the .eap extension here, and trace where the day, month and year fields come from before you change either clock.
Open the project in the panel's programming software and find the report or email configuration. Record three things: which clock supplies the date fields; whether the date is read as one value or assembled from separate fields; and whether the send schedule uses the same clock the printed timestamp uses. Treat the schedule and the printed date as two paths until the project shows they share a source.
If the project is not on hand, an upload from the panel may work. If the project was saved as protected when it was downloaded, the upload may not be possible, and the comparison pass in the next section is what decides the question without the project.
How do I compare the panel clock, the PLC clock and a fresh report in one pass?
Read both clocks against a trusted reference inside the same minute, then trigger one manual test send. You then hold three values taken at one moment: panel date and time, PLC date and time, and the date printed on a report you just generated.
- Open a trusted reference, a phone or a PC showing network time, and note the date and time.
- Read the panel clock in its time settings and write down day, month, year and time. Stay inside the same minute as the next step, because a date rolls over at midnight while you look.
- Read the PLC clock through your PLC programming software and write down the same four values.
- Trigger one manual test send and record the date printed in the report body.
- Match the test report against the two clock readings. The value it matches is the source the report reads. A report that matches neither live clock is being built from stored values in the project, which the scenario below carries through.
Where is the clock setting on the panel?
Panel clocks sit behind a setup screen, reached on many touch panels by pressing and holding a corner for a few seconds. On one documented panel family the path is HMI Control Panel > Time & Date with a daylight saving time checkbox to match your location.
The exact gesture and menu differ by panel family, so use the manual for yours. A daylight saving mismatch shifts the whole timestamp by one hour, so it is not this fault, but correct it while you are in the menu. PLC clocks are read and set through the controller's date and time settings in your PLC programming software. The same clock-and-timestamp discipline applies to any screen on the floor, including the shop-floor display boards we build.
Could real-time-clock drift cause a two-day error?
No: a quartz real-time clock with the standard crystal tolerance of about ±20 ppm drifts roughly 1.7 seconds per day. Two full days, 172,800 seconds, would take on the order of 100,000 days of drift, and the time of day would be wrong long before the date was.
Here is the arithmetic. A standard quartz crystal is specified at about ±20 ppm. One day holds 86,400 seconds, so the worst drift is 86,400 s × 0.00002 = 1.728 seconds per day, call it 1.7. Over a year that is 1.7 × 365 ≈ 631 seconds, about 10.5 minutes.
For drift to move a clock two days, it would have to fall behind by 2 × 86,400 s = 172,800 seconds. At 1.728 seconds per day that takes 172,800 ÷ 1.728 = 100,000 days, roughly 274 years. Drift also shows in the time of day first: a clock two days slow does not read the correct hour and minute. Your emails carry the correct time, so drift is ruled out, and a battery swap does not address this fault.
Scenario: what do three readings show after two missed sends?
A line's report is due daily at 06:00, sends on Tuesday the 4th, fails on the 5th and the 6th, and Friday the 7th's email carries the correct time but is dated the 5th, two days behind the calendar.
Run the comparison pass at 10:15 on the 7th:
- Trusted reference: Friday the 7th, 10:15.
- Panel clock: the 7th, 10:15. Correct.
- PLC clock: the 7th, 10:15. Correct.
- Forced test send at 10:16: the report body still prints the 5th.
Both clocks are right, so neither needs changing, yet the fresh report still carries the stale date. The report reads a stored date value, one that only moved when a report went out, and the two missed sends left it two days behind. The fix is in the project's report logic, not in either clock.
The other outcomes decide differently. If the PLC clock had read the 5th at 10:15 and the test report matched it, correct the PLC clock and verify with a test send and the next scheduled one. If the forced test report had printed the 7th, the timestamp reads a live clock and the next scheduled send should already be correct; then check the inbox date column case from the symptom list.
What do I change once I know which clock is wrong?
Correct only the clock the fresh report matched, the panel clock in its time settings or the PLC clock through your PLC programming software. Change nothing else, because a second change hides which action fixed the fault.
Back up the project first; a copy you can restore is the difference between a five-minute fix and a rebuild. Then take the branch your comparison pass chose:
- Panel clock behind: correct it in the panel's time settings, with the daylight saving box matching your location.
- PLC clock behind: correct it through your PLC programming software. If the panel writes the PLC clock rather than only reading it, make the correction from the panel so both devices hold the same time.
- Both clocks correct and the fresh report stale: correct the report logic in the project so the day, month and year fields are read at generation time. If the project assembles the date from separate registers, check each field's data format against the PLC values, because a unit or format mismatch corrupts these fields.
Deploy any project change by the site's normal approved method, and leave the schedule and the email settings untouched this round.
Recommendation: Before you touch any clock, run the one-pass comparison: panel clock, PLC clock and a forced test report, all recorded inside the same minute. Correct only the clock the test report matches. If both clocks already read the correct date, leave them alone and fix the report's date source in the project, with a backup taken first. Then confirm two consecutive scheduled sends before you call the fault closed.
How do I verify the next scheduled send stays correct?
Watch two consecutive scheduled sends, not just one. Force a test report dated today, then let the next 06:00 send run, and only when that scheduled email arrives with the current day of month is the fault closed.
One arriving email verifies that send; it does not prove the daily trigger will keep running, so watch the send after it as well. If a send is missed again, write down five values while they are fresh: the panel clock, the PLC clock, the report's configured date source, the scheduled send time, and the day printed in the email. Those five lines separate a send or schedule failure from a stale date source, and they turn the next pass into a lookup instead of a search.
Questions
Can a weak real-time-clock battery cause a date error like this?
A failing backup battery shows itself after a power loss: the panel comes back with the clock unset or at a default date, so the time of day is wrong too. Your emails carry a correct time of day, which does not match a panel that lost its clock. Check the battery after power-loss faults, and treat a date that lags by the number of missed sends as a report-source problem.
How far should a panel clock drift over a year?
With the standard quartz tolerance of about ±20 ppm, expect up to roughly 1.7 seconds per day, about 10.5 minutes across a year. That is far too small to move a date, but enough to matter for timestamps, so check the panel clock against a trusted reference a few times a year, or sync it from the network if the panel offers that.
Could a power cut have caused the two-day lag?
A power cut long enough to lose two calendar days lasts 48 hours, and a panel without power that long shows it in the time of day as well, not just the date. Emails with a correct time of day mean the panel kept running and kept time. The lag sits in the report's date source, which is what the comparison pass tests.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.