To convert CST to EST, add 1 hour. 9:00 AM Central is 10:00 AM Eastern, and 11:30 PM Central is 12:30 AM Eastern the next day. In summer the two zones are on CDT and EDT, and the gap is still 1 hour, because both switch to daylight time on the same dates.
That rule covers almost every hour of the year. It fails in three places: one hour each March and November when the clocks change at different moments, regions that call themselves Central or Eastern but skip daylight time, and Manitoba, which stops falling back on November 1, 2026. This guide covers all three. Every code output below came from running it on Ubuntu 24.04 with tzdata 2026e.
CST to EST conversion chart
Add one hour to any Central time to get Eastern time. The chart works for both seasons: CST to EST in winter, CDT to EDT in summer.
| Central (CT) | Eastern (ET) | Central (CT) | Eastern (ET) |
|---|---|---|---|
| 12:00 AM | 1:00 AM | 12:00 PM | 1:00 PM |
| 1:00 AM | 2:00 AM | 1:00 PM | 2:00 PM |
| 2:00 AM | 3:00 AM | 2:00 PM | 3:00 PM |
| 3:00 AM | 4:00 AM | 3:00 PM | 4:00 PM |
| 4:00 AM | 5:00 AM | 4:00 PM | 5:00 PM |
| 5:00 AM | 6:00 AM | 5:00 PM | 6:00 PM |
| 6:00 AM | 7:00 AM | 6:00 PM | 7:00 PM |
| 7:00 AM | 8:00 AM | 7:00 PM | 8:00 PM |
| 8:00 AM | 9:00 AM | 8:00 PM | 9:00 PM |
| 9:00 AM | 10:00 AM | 9:00 PM | 10:00 PM |
| 10:00 AM | 11:00 AM | 10:00 PM | 11:00 PM |
| 11:00 AM | 12:00 PM (noon) | 11:00 PM | 12:00 AM, next day |
Only the last row changes the date. Anything from 11:00 PM to 11:59 PM Central is already tomorrow in Eastern time. A deadline of "end of day Friday, Central" is 12:59 AM Saturday for someone in New York.
As of October 27, 2026, Chicago is on CDT (UTC-5) and New York is on EDT (UTC-4). Both fall back on November 1. In UTC terms, CST is UTC-6 and EST is UTC-5. If you need UTC itself, the UTC to EST guide and UTC to CST guide have their own charts.
The two hours a year when Central and Eastern are not 1 hour apart
US clocks change at 2:00 AM local time, so Eastern changes an hour before Central does. For one hour in March the two zones are 2 hours apart, and for one hour in November they show the same time. The federal rule sets the second Sunday of March and the first Sunday of November. These are the exact windows, taken from zdump -v for America/Chicago and America/New_York:
| Window (UTC) | Chicago shows | New York shows | Gap |
|---|---|---|---|
| 2026-03-08 07:00 to 08:00 | 1:00 to 1:59 AM CST | 3:00 to 3:59 AM EDT | 2 hours |
| 2026-11-01 06:00 to 07:00 | 1:00 to 1:59 AM CDT | 1:00 to 1:59 AM EST | 0 hours |
| 2027-03-14 07:00 to 08:00 | 1:00 to 1:59 AM CST | 3:00 to 3:59 AM EDT | 2 hours |
| 2027-11-07 06:00 to 07:00 | 1:00 to 1:59 AM CDT | 1:00 to 1:59 AM EST | 0 hours |
Two hours a year sounds harmless. It is not, if your code does central_time + timedelta(hours=1). That line is wrong during both windows, and it gives no hint that anything went wrong. Overnight batch jobs, on-call handoffs, and anything scheduled around 1:00 to 3:00 AM sit right inside these windows.
The fix is to never add the hour yourself. Convert through real zones and let the time zone database decide.
How to convert Central Time to Eastern Time in code
To convert Central time to Eastern time in code, attach the America/Chicago zone to the local time, then convert to America/New_York. Avoid the zone names CST and EST. In most runtimes EST is a fixed UTC-5 that never switches to daylight time, and CST either fails or means something else; the UTC to CST guide has the full test table.
Python 3.9+
from datetime import datetime
from zoneinfo import ZoneInfo
central = datetime(2026, 10, 27, 9, 0, tzinfo=ZoneInfo("America/Chicago"))
eastern = central.astimezone(ZoneInfo("America/New_York"))
print(eastern.strftime("%Y-%m-%d %H:%M %Z"))
# 2026-10-27 10:00 EDT
JavaScript with Temporal
import { Temporal } from 'temporal-polyfill';
const central = Temporal.PlainDateTime.from('2026-10-27T09:00')
.toZonedDateTime('America/Chicago', { disambiguation: 'reject' });
central.withTimeZone('America/New_York').toString();
// '2026-10-27T10:00:00-04:00[America/New_York]'
Node.js 24 does not ship Temporal yet, so this uses temporal-polyfill 1.0.6. The old Date object can't do this well: it has no way to say "this wall-clock time is in Chicago" unless you build the offset string yourself, which brings the hardcoded-offset problem back.
PostgreSQL
SELECT TIMESTAMP '2026-10-27 09:00'
AT TIME ZONE 'America/Chicago'
AT TIME ZONE 'America/New_York';
-- 2026-10-27 10:00:00
The first AT TIME ZONE turns the Central wall time into an instant. The second renders that instant in Eastern.
Shell (GNU date)
TZ=America/New_York date -d 'TZ="America/Chicago" 2026-10-27 09:00' '+%F %H:%M %Z'
# 2026-10-27 10:00 EDT
The TZ="..." inside the date string sets the input zone, and the TZ= prefix sets the output zone. macOS ships BSD date, which lacks this syntax; brew install coreutils gives you gdate.
What each tool does with a time that doesn't exist, or happens twice
On March 8, 2026, Chicago clocks jump from 1:59 AM to 3:00 AM, so 2:30 AM never happens. On November 1, 2026, 1:30 AM happens twice, once in CDT and once in CST. Hand those two inputs to the snippets above and they disagree:
| Tool | 2:30 AM Central, Mar 8 (skipped) | 1:30 AM Central, Nov 1 (repeated) |
|---|---|---|
Python 3.12 zoneinfo, default fold=0 |
4:30 AM EDT, no error | 1:30 AM EST |
Java 21 ZonedDateTime.of (documented) |
4:30 AM EDT | 1:30 AM EST |
Temporal, default 'compatible' |
4:30 AM EDT | 1:30 AM EST |
Temporal, 'reject' |
RangeError |
RangeError |
date-fns-tz 3.2 fromZonedTime |
3:30 AM EDT | 1:30 AM EST |
| PostgreSQL 18 | 4:30 AM EDT | 2:30 AM EST |
| GNU date 9.4 | invalid date error |
1:30 AM EST |
Most tools read the repeated 1:30 AM as the first one (CDT). PostgreSQL picks the second, and its documentation explains why: an ambiguous time "is assigned the UTC offset that prevailed just after the transition," which in most zones means "the standard-time interpretation is preferred when in doubt." So a scheduler that writes the time in Python and a report that reads it back through SQL can be an hour apart, for one hour a year.
For the skipped time, date-fns-tz is the odd one out. It lands an hour earlier than everything else. Its repeated-hour answer also depends on the machine's own time zone: the table row comes from a server set to UTC, and the same call on a machine set to an Asia zone returned 2:30 AM EST instead. Only GNU date and Temporal's 'reject' mode tell you the input was impossible.
If the input comes from a person (a form, a CSV, a meeting request), reject both cases or ask, rather than guessing. In Python, compare the two fold values; if the offsets differ, the time is either skipped or repeated:
from datetime import datetime, timezone
from zoneinfo import ZoneInfo
CHICAGO = ZoneInfo("America/Chicago")
NEW_YORK = ZoneInfo("America/New_York")
def central_to_eastern(naive: datetime) -> datetime:
a = naive.replace(tzinfo=CHICAGO, fold=0)
b = naive.replace(tzinfo=CHICAGO, fold=1)
if a.utcoffset() != b.utcoffset():
# Either the time is skipped (spring) or repeated (fall).
if a.astimezone(timezone.utc).astimezone(CHICAGO).replace(tzinfo=None) != naive:
raise ValueError(f"{naive} does not exist in Central Time")
raise ValueError(f"{naive} happens twice in Central Time; pass fold")
return a.astimezone(NEW_YORK)
2026-10-27 09:00 -> 2026-10-27 10:00 EDT
2026-03-08 02:30 -> ValueError: 2026-03-08 02:30:00 does not exist in Central Time
2026-11-01 01:30 -> ValueError: 2026-11-01 01:30:00 happens twice in Central Time; pass fold
The fold attribute is described in the Python datetime docs. Passing fold=1 picks the second 1:30 AM, which converts to 2:30 AM EST. Temporal's disambiguation option ('earlier', 'later', 'compatible', 'reject') does the same job and is covered on MDN's Temporal.ZonedDateTime page. The date to Unix timestamp guide goes deeper on how languages resolve local times.
Places where Central to Eastern is not 1 hour
Plenty of places use the names "Central" or "Eastern," or the labels CST and EST, without following US daylight time. For them "add one hour" is right in winter and wrong in summer, or wrong all year. Here is 9:00 AM local time in each zone, converted to New York, computed with Python and tzdata 2026e:
| Region | IANA zone | 9:00 AM local, January 2027 | 9:00 AM local, July 2027 |
|---|---|---|---|
| Chicago, Dallas, Nashville | America/Chicago |
10:00 AM in NY (+1) | 10:00 AM in NY (+1) |
| Saskatchewan | America/Regina |
10:00 AM (+1) | 11:00 AM (+2) |
| Mexico City, Monterrey | America/Mexico_City |
10:00 AM (+1) | 11:00 AM (+2) |
| Guatemala, Costa Rica, Honduras | America/Guatemala, etc. |
10:00 AM (+1) | 11:00 AM (+2) |
| Alberta (labeled CST from Nov 2026) | America/Edmonton |
10:00 AM (+1) | 11:00 AM (+2) |
| Manitoba (labeled EST from Nov 2026) | America/Winnipeg |
9:00 AM (0) | 10:00 AM (+1) |
| Cancún, Panama, Jamaica | America/Cancun, America/Panama |
9:00 AM (0) | 10:00 AM (+1) |
The bottom rows matter even if you only care about North America. Cancún runs on EST all year, so a hotel booking system that treats "EST" as "New York time" is an hour off every summer.
Canada changed the map in 2026
Manitoba was the textbook Central Time province. Not anymore. The Manitoba government announced on September 17, 2026 that "Manitobans' clocks will not revert to standard time on Nov. 1." Winnipeg stays at UTC-5 permanently. The tz database NEWS file for release 2026e says it will "model this with its traditional abbreviation EST."
Alberta made a similar move earlier in the year. It is staying at UTC-6 and will not fall back on November 1, and tzdata 2026c labels that offset CST. The Northwest Territories followed in 2026d. British Columbia went first, in March, and the PST to EST guide covers what that does to Vancouver. After November 1, a Canadian timestamp labeled CST is likely to come from Edmonton or Yellowknife, and one labeled EST may come from Winnipeg.
So from November 1, 2026, CST to EST for Winnipeg is no conversion at all in winter. Winnipeg and New York read the same clock time until March, then Winnipeg matches Chicago for the summer.
The 2026e release left one open question: whether the parts of northwestern Ontario that have historically followed Winnipeg would follow it this time. Release 2026f (October 27, 2026) settled it. Ontario issued a regulation letting those areas stay aligned with Winnipeg, so they move to year-round UTC-5 as well, and no new zone was needed.
Stale time zone data gets Winnipeg wrong
These changes only reach your code when its tz data updates, and not every runtime reads the system copy. Here is 2026-11-16T15:00:00Z converted on one machine with the system tzdata at 2026e. The correct answers are 10:00 AM EST for Winnipeg and 9:00 AM CST for Edmonton.
| Runtime | Where its tz data comes from | Winnipeg | Edmonton |
|---|---|---|---|
Python 3.12 zoneinfo |
System /usr/share/zoneinfo (2026e) |
10:00 EST | 09:00 CST |
| GNU date 9.4 | System (2026e) | 10:00 EST | 09:00 CST |
| Node.js 24.18.1 | Bundled ICU 78.3, process.versions.tz = 2026b |
9:00 AM CST | 8:00 AM MST |
| PostgreSQL 18.6 (PGlite 0.5.12) | Bundled, has Alberta's 2026c change but not Manitoba's 2026e | 09:00 | 09:00 |
Same machine, same instant, one-hour disagreements, and the two stale runtimes are stale in different ways. Node and the PGlite build carry their own snapshot, so updating the OS package doesn't touch them. Check process.versions.tz in Node, SELECT version() plus your distribution's tzdata package for PostgreSQL, and the tzdata version listed in your JDK's release notes for Java, which also bundles its own copy. If you have users in Manitoba or Alberta, verify the version before November 1.
Calendars are affected too. Microsoft's Outlook guidance tells users in the three provinces to switch to new zones such as "(UTC-05:00) Manitoba" and to migrate upcoming meetings, and warns that exceptions in recurring series "will be reset."
US states split between Central and Eastern time
Five US states are split between the Central and Eastern zones, so a state is not enough to pick a time zone. Use the location's IANA zone instead. The legal boundaries live in 49 CFR Part 71, maintained by the Department of Transportation.
| State | Central part | Eastern part | Zones you will see |
|---|---|---|---|
| Indiana | 12 counties: Gary/Lake County area in the northwest, Evansville area in the southwest | Indianapolis and most of the state | America/Chicago, America/Indiana/Knox, America/Indiana/Tell_City, America/Indiana/Indianapolis |
| Kentucky | Western half (Bowling Green, Paducah) | Eastern half (Louisville, Lexington) | America/Chicago, America/Kentucky/Louisville, America/New_York |
| Tennessee | Middle and West (Nashville, Memphis) | East (Knoxville, Chattanooga) | America/Chicago, America/New_York |
| Florida | Most of the Panhandle west of the Apalachicola River (Pensacola) | The rest, including Tallahassee | America/Chicago, America/New_York |
| Michigan | Four Upper Peninsula counties on the Wisconsin border | Everything else | America/Menominee, America/Detroit |
All of these follow US daylight time today, so CST to EST between them is the usual +1. The bug is upstream: a signup form that asks for a state and maps "Tennessee" to Eastern puts Nashville an hour off for every appointment. Ask for the zone directly, or derive it from coordinates, and store the IANA name with the user record.
Scheduling meetings and jobs across Central and Eastern
For a recurring event, store the time with the zone it was set in, not as a UTC instant. A weekly 9:00 AM Central standup stored as 15:00Z shows as 10:00 AM Eastern all winter, then shifts to 11:00 AM in March when Chicago moves to UTC-5. Store 09:00 plus America/Chicago, compute each occurrence in that zone, and convert for display.
Cron jobs have the same problem. A crontab on a UTC server runs at a fixed UTC time, so its Central and Eastern times both drift an hour twice a year. cronie supports CRON_TZ=America/Chicago and Kubernetes CronJobs accept a timeZone field. Avoid scheduling anything between 1:00 and 3:00 AM local, because those are the hours that are skipped or repeated. The cron and crontab guide covers both settings, and the cron job generator builds and explains expressions offline.
Checking a Central to Eastern conversion offline
SelfDevKit's timestamp converter shows one moment in several zones side by side, including America/Chicago and America/New_York, so you can read the Central and Eastern times together. It runs on your machine, which matters when the timestamp comes from a production log next to hostnames and request IDs.
Paste an ISO 8601 string with an explicit offset, such as 2026-10-27T09:00:00-05:00 for 9:00 AM CDT. Leave the offset off and the converter reads the value as your local time, which is only Central time if you already live there. Unix timestamps in seconds or milliseconds work too; convert Unix timestamp explains how to tell which one you have. The zone labels come from your system locale, so they may read CDT/EDT or GMT-5/GMT-4.
The converter shows a fixed set of common zones, so it covers Chicago and New York but not Winnipeg or Edmonton. For those, use the code above with up-to-date tz data.
Quick answers
Is Central time 1 or 2 hours behind Eastern?
One hour, all year, between Chicago and New York. The only exceptions are a one-hour window each March (2 hours) and each November (0 hours) when the clocks change. Places that skip daylight time, like Saskatchewan and Mexico City, are 2 hours behind New York in summer.
What is 12 PM CST in EST?
1:00 PM EST. In summer, 12:00 PM CDT is 1:00 PM EDT.
How do I convert EST to CST?
Subtract 1 hour. 3:00 PM Eastern is 2:00 PM Central. If the time falls between 1:00 and 3:00 AM on a clock-change night, convert through the IANA zones in code instead of doing it by hand.
Is "CST" always US Central time?
No. CST is also China Standard Time (UTC+8), and many Linux servers in China print it in logs. From November 2026, Alberta's year-round UTC-6 is labeled CST as well. If a timestamp's label is all you have, check where it came from before converting.
Try it yourself
SelfDevKit puts the timestamp converter, cron generator, and 50+ other developer tools in one offline desktop app, so log timestamps never leave your machine.
Download SelfDevKit to convert Central, Eastern, and UTC times without opening a browser tab.
