DEV Community: Premysl Hnevkovsky

We're Inside the DST Gap Right Now — Your Code Might Not Be

Premysl Hnevkovsky — Wed, 25 Mar 2026 22:53:15 +0000

A field guide for developers building apps that dare to cross meridians

You decided to build an app that tracks events worldwide. Bold move. Now let's talk about the moment you realize that time is not a simple integer and your clever Date.now() will absolutely betray you at the worst possible moment.

Welcome to timezone hell. Population: every developer who ever shipped a scheduling feature.

⚠️ Real-time relevance: I'm writing this on March 24, 2026 — and we're currently living inside the US–Europe DST gap window. The US switched to EDT on March 8, but Europe doesn't switch to CEST until March 29. If your app hardcodes timezone offsets between New York and London (or Prague, or Paris), it's wrong right now.

Step 1 — Know Where You Are (Spoiler: It Doesn't Matter)

You live somewhere. You know your timezone. Congratulations, that's completely irrelevant to your backend.

Your server doesn't care about Prague. Your server speaks UTC.

GMT vs UTC: GMT is a timezone. UTC is a time standard. They happen to share the same offset (+00:00), but GMT observes DST in some edge cases and is rooted in astronomical observation. UTC is atomic-clock precise and DST-free. Always store UTC. Never argue about this.

// Server Side - Kotlin 

// ❌ Don't do this
val now = LocalDateTime.now() // Whose now? YOUR now? Server's now? Tokyo's now? 

// ✅ Do this
val now = Instant.now() // Universal. Unambiguous. Boring in the best way.

Step 2 — Know Where the Event Is

Your app cares about Tokyo Stock Exchange opening at 09:00 JST That's Tokyo's clock. Not yours.

First: get the canonical event time in its home timezone.

// Server Side - Kotlin

val tokyoZone = ZoneId.of("Asia/Tokyo")
val tokyoOpen = ZonedDateTime.of(
    LocalDate.now(tokyoZone),
    LocalTime.of(9, 0),
    tokyoZone
)
// tokyoOpen = 2026-03-24T09:00+09:00[Asia/Tokyo]

Now convert to UTC so you have a real anchor point:

// Server Side - Kotlin

val tokyoOpenUtc = tokyoOpen.toInstant()
// 2026-03-24T00:00:00Z  ← this is your ground truth

Good. Now you have something you can actually compute with.

Step 3 — The Countdown Is Just Subtraction (Or Is It?)

// Server Side - Kotlin

val countdown = Duration.between(Instant.now(), tokyoOpenUtc)
println("Market opens in: ${countdown.toMinutes()} minutes")

Easy, right? Ship it.

...

Wait.

Step 4 — Did You Think About DST?

Japan doesn't observe DST. Lucky them. But your users might live somewhere that does.

Here's the trap: your countdown is correct (you're comparing Instant values — UTC under the hood). But the displayed local time on the client side may shift by ±1 hour depending on the season.

// Client side - TypeScript

const winterTs = new Date("2026-01-15T00:00:00Z");
winterTs.toLocaleString(undefined, { timeZoneName: "short" });
// Prague: "15. 1. 2026, 1:00:00 CET"   ← UTC+1, winter time

const summerTs = new Date("2026-06-01T00:00:00Z");
summerTs.toLocaleString(undefined, { timeZoneName: "short" });
// Prague: "1. 6. 2026, 2:00:00 CEST"   ← UTC+2, summer time !

Same code. Different timestamp. Different hour. The browser handles the rule — but only if you let it. The moment you hardcode +01:00 you're frozen in January forever.

Use ZoneId, not ZoneOffset. One knows about DST. The other does not.

// Server Side - Kotlin

// ❌ Hardcoded offset - breaks in summer/winter
val prague = ZoneOffset.of("+01:00")

// ✅ Named zone - handles DST transitions automatically
val prague = ZoneId.of("Europe/Prague")

Step 4.5 — The DST Overlap Problem (This Is Where It Gets Spicy) 🌐

Here's what most tutorials skip: different regions switch DST on different dates.
And that gap between switches is where hardcoded timezone differences silently break.

The US–Europe Gap Window (happening right now)

As of this writing — late March 2026 — we are living inside exactly this trap:

🇺🇸 US switched to EDT on March 8 (second Sunday of March)
🇪🇺 Europe switches to CEST on March 29 (last Sunday of March)

That's 3 weeks where the US–Europe offset is not the usual value:

Period                  | New York (ET) | Prague (CET/CEST) | Difference
------------------------|---------------|-------------------|------------
Winter (before Mar 8)   | EST  = UTC-5  | CET  = UTC+1      | 6 hours
Gap window (Mar 8–28)   | EDT  = UTC-4  | CET  = UTC+1      | 5 hours💥
Summer (after Mar 29)   | EDT  = UTC-4  | CEST = UTC+2      | 6 hours

If you hardcoded "NYSE opens 3:30pm Prague time" — you're wrong for 3 weeks every spring and 3 weeks every autumn. Congratulations, your bug has a season.

// Server Side - Kotlin

// ❌ This is wrong 6 weeks per year
val nyseOpenInPrague = LocalTime.of(15, 30) // "I know the offset is 6h"

// ✅ Let the library do the calendar math
val nyseOpen = ZonedDateTime.of(
    LocalDate.now(ZoneId.of("America/New_York")),
    LocalTime.of(9, 30),
    ZoneId.of("America/New_York")
)
val pragueView = nyseOpen.withZoneSameInstant(ZoneId.of("Europe/Prague"))
println("NYSE opens at: ${pragueView.toLocalTime()} Prague time")
// Correctly prints 15:30 in winter, 15:30 in summer, and 14:30 in the gap 🎯

The Australia Wildcard — When the Hemispheres Collide

Australia is on the opposite DST schedule because, well, opposite hemisphere. The ASX (Sydney) observes:

AEDT (UTC+11) — October through April (their summer)
AEST (UTC+10) — April through October (their winter)

This creates a beautiful four-state matrix with Europe alone:

Period               | Sydney        | London (GMT/BST) | Difference
---------------------|---------------|------------------|------------
Jan (EU winter,      | AEDT = UTC+11 | GMT  = UTC+0     | 11 hours
 AU summer)          |               |                  |
Apr transition week  | AEST = UTC+10 | BST  = UTC+1     | 9 hours 💥
Jul (EU summer,      | AEST = UTC+10 | BST  = UTC+1     | 9 hours
 AU winter)          |               |                  |
Oct transition week  | AEDT = UTC+11 | BST  = UTC+1     | 10 hours 💥

The Sydney–London offset swings between 9 and 11 hours across the year, with two transition windows where it's a completely different value than either stable state.

Any app that displays "London time" relative to "Sydney time" from a hardcoded diff will be wrong four times per year, at transitions in both directions.

The only correct approach:

// Client Side - TypeScript

function getOffsetBetween(zone1: string, zone2: string, at: Date): number {
  // Never hardcode. Always compute. Timezone rules do the rest.
  const fmt = (tz: string) =>
    new Intl.DateTimeFormat("en", { timeZone: tz, timeZoneName: "shortOffset" })
      .formatToParts(at)
      .find(p => p.type === "timeZoneName")?.value ?? "";

  const parseOffset = (s: string) => {
    const m = s.match(/GMT([+-])(\d+)(?::(\d+))?/);
    if (!m) return 0;
    return (m[1] === "+" ? 1 : -1) * (parseInt(m[2]) * 60 + parseInt(m[3] ?? "0"));
  };

  return parseOffset(fmt(zone1)) - parseOffset(fmt(zone2));
}

// Usage
const now = new Date();
console.log(getOffsetBetween("Australia/Sydney", "Europe/London", now));
// Returns the correct value today, tomorrow, and in October

The Summary Rule

If you have ever typed a number of hours as a timezone difference between two places — you have a bug. You just don't know which week it will appear yet.

Step 5 — Did You Consider the Date?

Tokyo opens Monday 09:00 JST. You're in New York on Sunday evening. The event is
tomorrow in Tokyo and today in your database query.

// Server Side - Kotlin

val tokyoZone = ZoneId.of("Asia/Tokyo")
val nyZone    = ZoneId.of("America/New_York")

val nowInTokyo = ZonedDateTime.now(tokyoZone)  // Monday
val nowInNY    = ZonedDateTime.now(nyZone)      // Sunday

// Same Instant. Different dates. Different days of the week.
// Your "today's events" filter just silently excluded Tokyo.

Rule: Always derive local dates from the event's timezone, not from your server's LocalDate.now().

Step 6 — Architecture: Server/Client Contract

🏗️ Here's the pattern that keeps you sane across the whole stack:

┌──────────────────────────────────────────────────────┐
│  SERVER                                              │
│  • Stores everything as UTC (Instant / epoch ms)    │
│  • Stores user's IANA timezone string alongside     │
│    user-facing timestamps                           │
│  • Never stores offsets (+01:00) — they're seasonal │
└───────────────────┬──────────────────────────────────┘
                    │ JSON: { "openTime": "2026-03-24T00:00:00Z",
                    │         "timezone": "Asia/Tokyo" }
┌───────────────────▼──────────────────────────────────┐
│  CLIENT                                              │
│  • Receives UTC timestamps                          │
│  • Renders in user's local timezone (browser API)   │
│  • Sends edits back as UTC or with explicit tz info │
└──────────────────────────────────────────────────────┘

// Client Side - TypeScript

// Server response contract
interface MarketEvent {
  openTimeUtc: string;    // ISO-8601 UTC: "2026-03-24T00:00:00Z"
  marketTimezone: string; // IANA: "Asia/Tokyo"
}

// Client rendering
function formatEventTime(event: MarketEvent, displayZone: string): string {
  return new Intl.DateTimeFormat("en-US", {
    timeZone: displayZone,
    hour: "2-digit",
    minute: "2-digit",
    timeZoneName: "short",
  }).format(new Date(event.openTimeUtc));
}

Step 7 — What About the Cloud ☁️ ?

"My app runs on three continents. Does my replica in Singapore care about Prague time?"

No. And it shouldn't.

Your databases store UTC-based timestamps:

Firestore / MongoDB → epoch-based UTC values (timezone is not stored at all)
PostgreSQL TIMESTAMPTZ → stored as UTC internally, converted on read/write

Timezones are not a storage problem.
They are a scheduling and interpretation problem.
And sometimes — they are your business logic.

The only time you should actually care about timezones in your backend:

Sharding data by date (whose “today”? see Step 5)
Log correlation across multi-region deployments
Scheduled jobs that must fire at "9am local" per region
Business rules tied to real-world time (markets, bookings, SLAs)

This is where many systems break.

Because this is NOT display logic — this is domain logic.

If your app says:

"Send email at 9:00"
"Market opens at 09:30"
"Booking starts at midnight"

That time belongs to a specific timezone, and must be modeled explicitly.

// Server Side - Kotlin

// ❌ Ambiguous — whose 9:00?
LocalTime.of(9, 0)

// ✅ Explicit — tied to real-world meaning
ZonedDateTime.of(date, LocalTime.of(9, 0), ZoneId.of("America/New_York"))

Never rely on your server region timezone (e.g. AWS region). It is irrelevant to your application logic.

For everything else: UTC in, UTC out, convert at the edges.

The Mental Model

Event happens in the real world
        ↓
Expressed in event's local timezone  (09:00 JST)
        ↓
Stored as UTC on your server         (00:00 UTC)
        ↓
Transmitted as UTC over the wire
        ↓
Displayed in user's local timezone   (browser/client)

🧠 That's it. The whole game. Fight anyone who breaks this pipeline.

🎯 Bonus: Real Lessons from Building TradeDialer

I built TradeDialer, a global market hours tracker covering 25 exchanges with live countdowns and index data.

Here's what actually hurt:

1. Countdown wording is a UX problem, not just a math problem

A raw duration like "opens in 61 hours" is technically correct and practically useless on a Friday afternoon. The countdown needs contextual language:

Opens in 2h 34m          ← same day, simple case
Opens Monday 09:30       ← weekend ahead
Opens in 3 days          ← holiday closure

Every one of those branches must be computed in the exchange's local timezone, not the server's. "Monday" in Tokyo is not "Monday" in New York.

2. Status thresholds need their own timezone logic

TradeDialer uses a four-state color system to communicate urgency at a glance:

Color	Meaning
🟢 Green	Market is open
🟡 Amber	Closing in < 1 hour
🔵 Blue	Opening in < 1 hour
⚫ Gray	Closed (weekend / holiday / outside hours)

The amber and blue thresholds are computed as a diff against the exchange's session end/start — as ZonedDateTime, not a raw UTC comparison. Otherwise the "closing soon" window misfires around DST transitions.

3. Live data fallback is a timezone-triggered state machine

When US markets close, direct exchange feeds dry up. TradeDialer automatically switches to a Yahoo Finance fallback for foreign markets that are still open — and surfaces the source change with a visible badge so users always know what they're looking at.

The trigger for that switch? Computed using exchange timezone + session hours. Not UTC midnight. Not server time. The exchange's own clock.

4. Holiday calendars are a maintenance tax, not a one-time task

Holiday data looks static — until a government announces a surprise market closure three days before it happens (this is a real thing that happens). Building a market hours app means committing to keeping holiday data fresh across 25 exchange calendars, globally.

Design your holiday config as versioned and hot-reloadable, not hardcoded constants. You will need to push an update on short notice someday.

5. Scope decisions must be explicit, not accidental

NYSE pre-market starts at 04:00 EST. NYSE after-hours runs until 20:00 EST. TradeDialer deliberately excludes extended hours and shows only regular session data.

"We don't show extended hours" is a product decision.
"Extended hours are broken" is a bug.
Know which one you're shipping.

TL;DR — The Timezone Survival Kit

Rule	Why
Store as `Instant` / UTC epoch	No offset confusion
Use IANA zone IDs, not offsets	DST is handled for you
Never hardcode hour differences between zones	The gap window will find you
Derive dates per-timezone	Date line is real
Convert only at display time	Single source of truth
Evaluate holidays in exchange timezone	Local days, not UTC days
Model data quality explicitly	Trust is a feature
Make holiday data hot-reloadable	Governments are unpredictable
Never trust `LocalDateTime` across systems	It's a lie with no context

Built while debugging why TradeDialer showed Tokyo as opening at 1am. It was. In Prague. In December. Nobody told the server.

Check it out: trade-dialer.com

I Spent Weeks Building a Clock for Global Stock Market Hours

Premysl Hnevkovsky — Fri, 20 Feb 2026 15:07:21 +0000

And a 20-Year Trader Didn't Laugh.

We live in the era of AI agents and overnight startups, "10x your productivity" threads, Full trading platforms with heat maps, AI signals, and blinking dashboards.

And I built... a clock.

A global stock market clock.

And it turned out to be much more complicated than I expected.

TL;DR: I built a simple global stock market hours tracker because I was tired of noisy trading dashboards. It became a lesson in time zones, scope creep, and why shipping beats perfection.

It Started With a Simple Question

Last year my son asked for a trading account.

After some evaluation (and strict limits), I opened one for him.
I tried mentoring. Mixed results. At least I convinced him not to start with crypto.

But one thing became obvious immediately:

Markets open and close.
And if you don't know when, you're already behind.

And yes — he still has some money left on his account.
Which I consider a success metric.

"Surely This Exists"

I just wanted to know:

Are US markets open right now?
When does Frankfurt close?
How much time do I have before the chaos begins?

Simple questions.

Surprisingly messy answers.

Yes, there are websites and apps listing trading hours. Yes, there are advanced trading platforms with everything bundled.

But I wanted something different.

A clean global overview
Clear states: open / closed / opens soon / closes soon
A countdown
And one small extra: major indices next to each exchange

Not a trading terminal.

Not every finance tool needs to be another Bloomberg terminal. 📈

So I built TradeDialer — a global stock market hours tracker with real-time countdowns and live indices.

The First Version

Well... there is a story of a first version built for my son.

I vibe-coded it.
Used it.
Published it.
Forgot about it.

Classic side project. 😴

Then I Reopened It

This January, I met a friend from the Prague dev community. We talked about AI, shipping fast, vibe coding, so I opened the app to show him.

It was broken with time glitches and wrong market states. Edge cases everywhere.

It looked simple.
It wasn't.
So I started fixing it.

Evenings.
Nights.
"Just one more bug."

You know the pattern. 🙄

"It's Just Time."

Narrator: It was not just time.

I've worked in software for years --- including finance.

So I confidently thought:

"Handling time zones and trading hours? Weekend project."

Here's what "just time" actually meant:

Global daylight saving chaos
Exchange-specific holidays
Partial trading days
Index hours ≠ exchange hours
API quirks
Rate limits
Caching strategies
Synchronization edge cases
Desktop vs. mobile version

Time is simple.

Until it spans the planet.

Backend Confidence vs Frontend Humility

I'm a backend developer, thus I took Kotlin & Spring Boot & microservices containerized stack.

Frontend?

Let's call it:

Vibe coding
Reviewing
Refactoring
Learning the hard way

Respect to frontend engineers. 👍

Infrastructure (Because Developers)

I like the proper setup.

Terraform.
GitHub Actions.
AWS (ECS + CloudFront).
Fully automated deployment.

For a clock.

Yes. I see the irony.

The "Reality Check" Moment

Then came the reality check.

I showed it to a friend who has been trading for decades.

He didn't laugh.

He didn't say "this is useless."

He calmly opened professional platforms with:

Heat maps
Real-time flows
Advanced dashboards
Enough information to overload three brains

I looked at him and said:

I'm not fighting those platforms.

I'm building for the person who opens a trading app and feels cognitively exhausted.

Too many colors.
Too many numbers.
Too many blinking things.

Maybe you don't need another dashboard.
Maybe you just need to know:

Is the market open?
When does it close?
What's the index doing?

That's it.

Change this:

Into this:

What I Learned so far

Small tools are never small.
Time is harder than distributed systems sometimes.
Estimation is fiction.
AI helps a lot --- but experience still matters.
Perfection is the enemy of shipping.

At some point, you push it live.

The Result

TradeDialer

A global stock market hours dashboard with:

Live open/close countdowns
Major indices
Clear filtering (active, sleeping, opens soon, closes soon)
Minimal cognitive load

No predictions.
No hype.
No trading signals.

Just time.

Maybe You're That Person

If you’ve ever Googled:

"Is NASDAQ open right now?"

Or you feel slightly overwhelmed by full trading dashboards…

Maybe this is for you.

I’m not trying to replace professional platforms.

I just wanted clarity.

If that resonates, you can check it out here:

👉 https://trade-dialer.com

And if you think it’s useless — tell me why.

That’s how small tools get better.

But I did spend weeks building a very sophisticated clock. ⏰