How I Fixed a 14-Hour Timezone Bug in My VS Code Extension 🕒🐛

💀 The Nightmare: "Why is my post 14 hours late?"

I recently released a major update for my VS Code extension, DotShare, which allows developers to schedule social media posts directly from their editor.

Everything seemed perfect in testing... until I tried to schedule a post for 12:00 PM.
Instead of posting at noon, the scheduler fired at 2:00 AM the next day.

A 14-hour delay. 😱

🔍 The Investigation

I dug into the logs and realized I was falling into the classic Timezone Trap:

1. The Input: The HTML datetime-local input gives a local time string (e.g., 2026-01-21T12:00).
2. The Mistake: I was converting this string directly using toISOString(), which assumed the input was UTC and subtracted my local offset (Egypt is UTC+2).
3. The Result: * 12:00 PM Local -> becomes 10:00 AM UTC in storage.
   • But my Scheduler Logic was comparing new Date() (Local) vs the Stored UTC.
   • Math: 12 hours (AM/PM confusion) + 2 hours (Timezone offset) = 14 Hours lag.

🛠️ The Fix: Trust No String, Use Unix Timestamps

I decided to nuke the complex Date object comparisons and go back to basics: Milliseconds.

Here is the refactored logic that solved it instantly:

1. The Storage (Neutral Ground)

Instead of fighting with Timezones, I store everything as a standardized ISO string, but I convert user input strictly based on Local Time first.

2. The Scheduler (The "Refree")

I changed the comparison logic to use .getTime(). This compares the absolute number of milliseconds since the Unix Epoch, ignoring timezones completely.

typescript
// Inside my Scheduler Service
public getScheduledPostsDue(now: Date = new Date()): ScheduledPost[] {
    const posts = this.loadScheduledPosts();
    const nowTime = now.getTime(); // Absolute milliseconds

    return posts.filter(p => {
        const scheduledDate = new Date(p.scheduledTime);
        const scheduledTime = scheduledDate.getTime();

        // Debugging the exact moment
        console.log(`[SCHEDULER DEBUG] Post ${p.id}: due=${scheduledTime <= nowTime}`);

        return p.status === 'scheduled' && scheduledTime <= nowTime;
    });
}

✅ The Result: Zero Latency
After refactoring, I tested it live. I set the schedule for 3:12 PM, and the Telegram message arrived the exact second the clock turned.

Watch the fix in action (50 sec):




🧠 Lessons Learned
Never trust datetime-local: Always parse it explicitly before sending it to your backend/storage.

Logs are your best friend: Adding [SCHEDULER DEBUG] logs saved me hours of guessing.

Math.floor is key: APIs like Telegram expect timestamps in Seconds, JavaScript gives Milliseconds. Always Math.floor(date.getTime() / 1000).

👋 I'm Freerave I build developer tools and VS Code extensions. If you found this helpful, check out DotShare on the VS Code Marketplace!