Telegram scheduled notifications: time zones, DST, and missed runs

“Send it at nine every day” leaves important decisions unresolved. Nine in which region? Should travel change the schedule? What happens after an outage? A server's default clock cannot answer these business questions.

A Daily Update Telegram Bot client brief asks for preset daily text-and-image updates, dispatch logs, and recovery after downtime. On November 3, 2026, the page displayed Open; its absolute publication date could not be established from the changing relative timestamp. This is a problem reference, not a BitBear delivery case. The policies below are proposed examples, rather than client quotations or existing product features.

Separate three different promises

• One instant: nine in Beijing on a particular date. Once confirmed, it can be represented by a UTC instant, retaining the original input and region for display.
• Nine every local morning: calculate occurrences against a named region's calendar. Across daylight-saving changes, consecutive runs need not be 24 hours apart.
• Every 24 hours: advance by a fixed duration from an agreed starting instant. The displayed local hour can change when clocks move.

Only the first can express its entire intention with a single UTC timestamp. A recurring plan should retain the region, local time, recurrence rule, and effective range. A stored next-run timestamp helps execution but must not replace that original intent.

For a local-morning digest, adding 86,400 seconds after each send can change the promised hour. A fixed-interval check may actually require that duration. Either is defensible when the confirmation clearly distinguishes them.

Store a region; do not infer it from language

The IANA Time Zone Database maintains regional clock rules and their changes. For a regional schedule, retain an identifier such as America/New_York or Asia/Shanghai, rather than just today's UTC offset. UTC-5 cannot describe all future daylight-saving behavior in a region. A Chinese interface does not establish Beijing time.

Ask for a region when creating the plan. Show the local date and time, region identifier, next UTC instant, and recurrence in the confirmation. If the user's profile time zone changes, ask whether existing plans should keep their original region or move to nine in the new region. A language change or a trip should not silently move confirmed notifications.

Time zone data needs maintenance. An unknown identifier or unavailable database should prevent confirmation with an explanation, rather than silently selecting the server's region.

Declare DST and month-end policies

Clock changes can make some local times nonexistent and others occur twice. A reminder in that window needs a declared policy: skip, move to a valid time, or ask for another selection; choose the first or second occurrence when a time repeats. Show the resolved result. A test on an ordinary day does not establish year-round behavior.

RFC 5545 distinguishes UTC, zoned local time, and floating time, and defines iCalendar date and recurrence semantics. An implementation claiming iCalendar behavior must follow the relevant clauses; a custom reminder policy must be identified separately. Do not describe a chosen shift-forward policy as every calendar library's default.

Month ends need the same care. “The 31st of each month” can skip months without that date; “the last day of each month” is a different rule. RFC 5545 recurrence rules ignore generated invalid dates rather than automatically clamping them to month end. If the business wants the last day, specify that rule and test February and leap years.

Outages and edits should not cause surprise catch-up

Consider this proposed daily-digest policy:

1. Keep a separate occurrence record for each plan and intended run, distinguishing scheduled and actual processing times.
2. After recovery, mark occurrences beyond an agreed grace period missed instead of sending several days of old reports. Decide separately whether to send within that grace period.
3. Version edits and cancellations. Before sending, a pending occurrence must check that its plan version remains active.
4. Show the first occurrence after an edit for confirmation. A past nine o'clock must not silently become “send immediately.”

These are proposed product requirements, not evidence that a scheduler implements them. Logs should also distinguish trigger execution, acceptance by the messaging API, and human reading; writing a dispatch log does not establish a read receipt. Recipient retries and rate limits are covered in the broadcast guide. This article defines which occurrence should exist in the first place.

Where BotFatherV2 fits, and what needs custom work

As checked November 3, 2026, BotFatherV2 supports AI-assisted creation and modification of Telegram Serverless bots, importing existing Serverless bots, publishing versions, and code rollback retaining current business data. The requested /en-US entry could not be retrieved; the accessible English homepage was used to verify these capabilities.

Its Build with AI documentation describes an initial scope of menus, simple community helpers, polls, and persistent tools isolated by user. The fixed SDK does not support arbitrary npm packages or Node/Bun APIs, and the initial release does not add paid-AI-dependent runtime features. The public documentation does not establish support for this complete scheduled-delivery design.

A first prototype could therefore describe commands to create, inspect, and cancel plan records, subject to checking field handling, isolation, and date support. Saving a time or manually listing due records does not establish that a bot can wake itself without an incoming message. Automatic triggers, time zone data, reliable recovery, image delivery, and external scheduler integration each need verification. Installing an npm scheduler cannot be assumed to work.

If the original VPS deployment, Python/Node source, and complete automatic delivery are mandatory, evaluate a separate custom project. An existing Serverless bot does not satisfy that stack by default. For a few manually arranged messages, evaluate existing client features first; subscription management, logs, and business controls may justify a full bot. BotFatherV2 operates independently of Telegram's official BotFather.

A brief for an AI builder or contractor

Design a daily-notification plan prototype first. The administrator explicitly selects a region time zone and local send time. Preserve that rule instead of using server defaults or interface language. Confirm the next local and UTC execution times. A profile region change must not silently alter existing plans. Before implementation, explain support for time zone calculations, automatic triggers without incoming messages, persistent occurrence records, and cancelling old versions. If unavailable, implement only command-driven record management and inspection, explicitly excluding scheduled delivery. If automatic delivery is commissioned separately, agree DST ambiguity, grace-period, and catch-up policies before demonstrating tests. Treat images, external spreadsheets, and VPS deployment as separate deliverables.

This template deliberately asks for capability gaps first. It makes no promise about price, delivery time, or unverified runtime features.

Test across time boundaries

• Compare local nine every morning with a 24-hour interval and verify that the implementation keeps them distinct.
• Test dates around a clock transition in a region observing DST, including nonexistent and repeated local times.
• Test the 31st, the last day, February, and a leap year without silently treating different rules as equivalent.
• Change one user's profile region; keep or migrate existing plans according to the confirmed policy, leaving other users unaffected.
• Cancel, edit, or restart before a due occurrence. Old versions must not send; missed runs follow the agreed policy.
• Verify genuine scheduled execution with no new chat messages. A manual command cannot establish automatic delivery.
• Check scheduled time, actual time, region, and occurrence status against an independent time reference.

Sources and verification

• Freelancer, Daily Update Telegram Bot, English client project 40189576. Publication date unknown; checked November 3, 2026, displaying Open. Only the client brief is summarized.
• IANA, Time Zones, continuously maintained without one publication date; checked November 3, 2026, for regional clock rules.
• B. Desruisseaux / IETF, RFC 5545: iCalendar, September 2009. Sections 3.3.5, 3.3.10, and 3.8.5.3 checked November 3, 2026. Supports time representation and recurrence semantics, not a claim of BotFatherV2 standards implementation.
• BitBear Studio, English homepage and Build with AI, capabilities checked November 3, 2026; the requested /en-US entry was inaccessible during verification.