Daily Local Time DST Audit — Skipped & Repeated Times avatar

Daily Local Time DST Audit — Skipped & Repeated Times

Pricing

$1.00 / 1,000 saved daily time audits

Go to Apify Store
Daily Local Time DST Audit — Skipped & Repeated Times

Daily Local Time DST Audit — Skipped & Repeated Times

Preview missing, unique and repeated daily wall-clock times across an IANA timezone date range, including every matching UTC instant and timezone database version. Offline, no scheduler changes.

Pricing

$1.00 / 1,000 saved daily time audits

Rating

0.0

(0)

Developer

Atesen Software

Atesen Software

Maintained by Community

Actor stats

0

Bookmarked

2

Total users

1

Monthly active users

4 days ago

Last modified

Categories

Security

Limited permissions

Share

What does Daily Local Time DST Audit do?

Find missing and repeated local times before scheduling a daily job. Give the Actor an IANA timezone, a local time and up to 31 consecutive dates. It returns every UTC instant that corresponds to that wall-clock minute, including zero instants during a spring-forward gap and two during a fall-back overlap.

The public source is the IANA Time Zone Database, shipped with Node.js. Every result includes the runtime's tzdbVersion. This is an offline date-range audit available through the Apify API; it does not connect to, create or change schedules.

Why audit a daily local time?

A daily 02:30 job does not always have one possible UTC execution time. Google Cloud Scheduler documents daylight-saving anomalies, and Apify schedules support timezone settings. Their actual skip, shift and duplicate policies must be checked separately.

Use this Actor to prepare a scheduler migration, inspect a delivery time around a DST transition, or attach a reproducible timezone audit to an operations ticket. Apify provides API access, saved datasets and integrations for passing the results to the next step. No API key for a time service or proxy is needed. For ordinary one-off timezone conversion, your operating system or a free timezone library may already suffice.

What data does the audit return?

FieldTypeMeaning
localDatestringCalendar date in the chosen timezone
classificationstringmissing, unique or repeated
occurrenceCountintegerNumber of matching UTC instants
utcOccurrencesarrayEvery matching instant, in chronological order
utcOffsetsMinutesarrayCorresponding offsets east of UTC
tzdbVersionstringRuntime timezone rule version

The remaining fields echo timeZone and localTime and explain the result in interpretation. A missing local time is a valid audit finding, not a request error.

How to audit a daily schedule time

  1. Open the Input tab and choose a named IANA timezone such as Europe/Berlin.
  2. Set localTime to a minute in HH:mm format, startDate to an ISO calendar date and days to 1–31.
  3. Run the Actor and inspect both the daily results and the linked STATE record. A partial dataset is not proof the whole range was audited.

The default example audits 02:30 on October 24–26, 2026 in Berlin. On October 25 it has two UTC counterparts, 00:30Z and 01:30Z, under the runtime's timezone rules. These are public calendar facts, not customer executions.

How much does the audit cost?

Pricing is $0.001 per successfully saved day audit ($1 per 1,000), with no Actor startup event. The default three-day example has $0.003 in result events. Actual pricing and available credits are shown in the Pricing tab; owner quality runs are not customer revenue. There is no fee for validation errors or STATE records. Normal platform rules and credits apply.

Set maxResults to limit saved days; zero skips scanning. The run spending limit is also checked before each day, using the undiscounted $0.001 rate conservatively. The Actor honors the SDK's acknowledged event limit and stops when no further event fits. No runtime external requests are made, even at positive budgets.

Input

See the Input tab for all configuration options.

{"timeZone":"Europe/Berlin","localTime":"02:30","startDate":"2026-10-24","days":3,"maxResults":31}

Dates are inclusive from startDate, with supported years 2000–2100. Fixed numeric offset strings are rejected. Named aliases supported by Node may work, but prefer canonical IANA names. There is no pagination; start a new run at the next date for a longer range. No retries or external authentication occur.

Output

You can download the dataset in various formats such as JSON, HTML, CSV, or Excel. JSON preserves the UTC arrays most directly.

{"localDate":"2026-10-25","timeZone":"Europe/Berlin","localTime":"02:30","classification":"repeated","occurrenceCount":2,"utcOccurrences":["2026-10-25T00:30:00.000Z","2026-10-25T01:30:00.000Z"],"utcOffsetsMinutes":[120,60],"tzdbVersion":"runtime version","interpretation":"Two or more UTC instants share this local time; scheduler duplicate handling varies."}

STATE records saved results, acknowledged events, aborts and result, time or budget limits. Invalid input fails the run with an explanation there and produces no charged error rows. On an abort, completed results remain available and completed stays false. The internal processing deadline is 200 seconds; normal default runs should finish much sooner.

Limits, FAQ and support

This does not parse cron expressions, decide which repeated occurrence a scheduler will choose, verify actual executions or guarantee future government timezone rules. It checks minute precision against the runtime's embedded timezone data. Rebuild when rules change and inspect tzdbVersion; it is not a live download of the latest IANA release. It also handles non-hour transitions and calendar dates skipped by offset changes within the supported period.

No personal data is requested or extracted. Send only timezone and calendar settings. Use the Issues tab for reproducible problems and the API tab for programmatic integration. Include the input, timezone database version and observed classification when reporting a discrepancy.