Gravity Forms incidents often span browser time, the WordPress site timezone, PHP or server UTC, SMTP provider time, webhook destination time, and a background queue. Copying those timestamps into one sheet without their original zones can reverse the event order or make a normal delay look like a missing request.
Use this when a form entry exists but email, webhook, CRM, payment, or notification evidence seems to occur earlier, later, or on another date. It is useful for distributed teams and sites near daylight-saving transitions.
Quick answer
Preserve every source timestamp exactly as recorded, add a named source timezone or offset, convert each event to UTC, and sort by normalized UTC plus a stable entry or request ID. Never overwrite the original timestamp. Flag rows whose timezone is unknown, then verify the sequence with at least one independent ID or provider event.
Test scenarios to run
Run the same controlled fixture across these branches. Write down the expected result before testing so a surprising response is easy to identify.
| Scenario | Fixture | Expected result |
|---|
| Normal notification | One test entry with a unique marker | Core, notification, provider, and delivery events sort in the expected order |
| Webhook retry | Endpoint returns one controlled 500 before success | Retries keep the same correlation key and increasing normalized times |
| DST repeated hour | Fixture around the fall offset change | Named timezone resolves both local occurrences without merging them |
| Unknown source zone | Log line without offset | Row remains flagged and is not treated as precise until source configuration is proven |
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Freeze source logs and record each system's timezone configuration. | Record the WordPress timezone setting, PHP timezone, operating-system timezone, database timezone, and provider display timezone. | Every timeline row retains original time, source, zone or offset, normalized UTC, event, and correlation ID. |
| Create the timeline columns before copying event rows. | Capture Gravity Forms entry ID, form ID, request or feed ID, notification ID, provider message ID, and queue action ID. | The sorted sequence matches known system dependencies and provider evidence. |
| Normalize timestamps with a tested timezone library and retain conversion notes. | Keep original timestamp text, source zone, UTC offset, normalized UTC, and conversion method in separate columns. | Duration calculations use normalized timestamps rather than display strings. |
| Join rows using entry, request, message, event, and action identifiers. | Identify daylight-saving gaps, repeated local hours, clock drift, and log lines that omit a year or offset. | Unknown or ambiguous timestamps remain visibly flagged and assigned for follow-up. |
What to check first
- Record the WordPress timezone setting, PHP timezone, operating-system timezone, database timezone, and provider display timezone.
- Capture Gravity Forms entry ID, form ID, request or feed ID, notification ID, provider message ID, and queue action ID.
- Keep original timestamp text, source zone, UTC offset, normalized UTC, and conversion method in separate columns.
- Identify daylight-saving gaps, repeated local hours, clock drift, and log lines that omit a year or offset.
- Sort the normalized timeline and calculate duration between each expected stage.
Field notes
- UTC is the comparison axis, not a replacement for the original evidence.
- Use an IANA timezone such as America/Chicago when converting policy dates. A numeric offset alone does not describe future daylight-saving behavior.
- Measure durations after normalization. Subtracting two unqualified local times can produce a confident but false result.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
original_time,source,source_zone,normalized_utc,correlation_id,event
2026-11-01 01:12:08,wordpress,America/Chicago,2026-11-01T06:12:08Z,GF-18422,entry_saved
2026-11-01T06:12:10Z,php,error_log,2026-11-01T06:12:10Z,GF-18422,feed_started
2026-11-01 07:12:13+01:00,mail_provider,Europe/London,2026-11-01T06:12:13Z,msg_9012,accepted
Why this usually happens
- WordPress can use a named local timezone while PHP and the host log in UTC.
- Provider dashboards may display the viewer's browser timezone rather than the account or event timezone.
- Daylight-saving transitions create ambiguous local timestamps that cannot be resolved from clock time alone.
Decision rule
Call a stage delayed or missing only after its source timezone is known and the normalized sequence is consistent with stable IDs. Treat unknown zones, drifting clocks, and ambiguous local hours as evidence gaps.
Production verification checklist
- Every timeline row retains original time, source, zone or offset, normalized UTC, event, and correlation ID.
- The sorted sequence matches known system dependencies and provider evidence.
- Duration calculations use normalized timestamps rather than display strings.
- Unknown or ambiguous timestamps remain visibly flagged and assigned for follow-up.
Safe fix order
Use a sequence that makes each result easy to prove. Stop when new evidence changes the scope or owner of the problem.
- Freeze source logs and record each system's timezone configuration.
- Create the timeline columns before copying event rows.
- Normalize timestamps with a tested timezone library and retain conversion notes.
- Join rows using entry, request, message, event, and action identifiers.
- Review unexplained gaps and publish the final UTC timeline with original evidence attached.
Mistakes to avoid
- Do not replace original timestamps with converted values.
- Do not assume a provider dashboard uses the WordPress timezone.
- Do not sort unqualified timestamp strings from several systems.
- Do not infer causation from event order when clocks or zones remain unverified.
Questions teams ask during testing
Should everything log in UTC?
UTC simplifies comparison, but some systems and business reports still display local time. Preserve both and document the source.
What if a log has no offset?
Prove the source configuration for that period or mark the timestamp as uncertain.
Can entry ID join every row?
Not always. Mail, webhook, and queue systems often introduce their own IDs, so preserve the mapping between them.
What to tell the client or owner
Share the source timezone inventory, normalized timeline, stable ID map, uncertain rows, measured delays, root cause, corrected configuration, and verification fixture.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, security, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
If this is active on a production site, trace a Gravity Forms incident across logs.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references