To convert UTC to CST, subtract 6 hours. That works from early November to mid-March. For the rest of the year Chicago, Dallas, and the rest of the US Central zone are on Central Daylight Time (CDT), which is UTC-5, so you subtract 5. 15:00 UTC is 9:00 AM in January and 10:00 AM in July.
The arithmetic is easy. The hard part is that "CST" is one of the most overloaded abbreviations in timekeeping. It also means China Standard Time (UTC+8) and Cuba Standard Time (UTC-5), and the runtime you use decides which one you get, sometimes without telling you.
UTC to CST conversion chart
Here is every UTC hour converted to US Central Time. Use the CST column between the first Sunday of November and the second Sunday of March, and the CDT column the rest of the year. On October 24, 2026, Chicago is still on CDT. It switches back to CST on November 1.
| UTC | CST (UTC-6), winter | CDT (UTC-5), summer |
|---|---|---|
| 00:00 | 6:00 PM, previous day | 7:00 PM, previous day |
| 01:00 | 7:00 PM, previous day | 8:00 PM, previous day |
| 02:00 | 8:00 PM, previous day | 9:00 PM, previous day |
| 03:00 | 9:00 PM, previous day | 10:00 PM, previous day |
| 04:00 | 10:00 PM, previous day | 11:00 PM, previous day |
| 05:00 | 11:00 PM, previous day | 12:00 AM (midnight) |
| 06:00 | 12:00 AM (midnight) | 1:00 AM |
| 07:00 | 1:00 AM | 2:00 AM |
| 08:00 | 2:00 AM | 3:00 AM |
| 09:00 | 3:00 AM | 4:00 AM |
| 10:00 | 4:00 AM | 5:00 AM |
| 11:00 | 5:00 AM | 6:00 AM |
| 12:00 | 6:00 AM | 7:00 AM |
| 13:00 | 7:00 AM | 8:00 AM |
| 14:00 | 8:00 AM | 9:00 AM |
| 15:00 | 9:00 AM | 10:00 AM |
| 16:00 | 10:00 AM | 11:00 AM |
| 17:00 | 11:00 AM | 12:00 PM (noon) |
| 18:00 | 12:00 PM (noon) | 1:00 PM |
| 19:00 | 1:00 PM | 2:00 PM |
| 20:00 | 2:00 PM | 3:00 PM |
| 21:00 | 3:00 PM | 4:00 PM |
| 22:00 | 4:00 PM | 5:00 PM |
| 23:00 | 5:00 PM | 6:00 PM |
The top of the table is where dates go wrong. In winter, anything from 00:00 to 05:59 UTC is still the previous calendar day in Chicago. That is a quarter of every UTC day. A nightly job logged at 2026-12-03T03:30:00Z ran on the evening of December 2, Central time, and a daily report that groups by UTC date will put it in the wrong day for Central users.
When Central Time switches between CST and CDT
US Central Time follows the same federal rule as the rest of the country: daylight time starts at 2:00 AM local on the second Sunday of March and ends at 2:00 AM local on the first Sunday of November. Because Central is an hour behind Eastern, the switch happens one hour later in UTC.
| Transition | Local wall clock | Exact UTC instant | Offset after |
|---|---|---|---|
| CDT starts, 2026 | Mar 8, 2:00 AM CST jumps to 3:00 AM CDT | 2026-03-08 08:00 UTC | UTC-5 |
| CST returns, 2026 | Nov 1, 2:00 AM CDT falls back to 1:00 AM CST | 2026-11-01 07:00 UTC | UTC-6 |
| CDT starts, 2027 | Mar 14, 2:00 AM CST jumps to 3:00 AM CDT | 2027-03-14 08:00 UTC | UTC-5 |
| CST returns, 2027 | Nov 7, 2:00 AM CDT falls back to 1:00 AM CST | 2027-11-07 07:00 UTC | UTC-6 |
These come from zdump -v America/Chicago with tzdata 2026e. On the night of November 1, 2026, the Chicago clock shows 1:30 AM twice: 06:30 UTC is 1:30 AM CDT and 07:30 UTC is 1:30 AM CST. Going from UTC to Central is never ambiguous. Going the other way can be. The UTC to EST guide walks through that repeated hour, and the date to Unix timestamp guide shows how each language picks an answer.
The rule could still change. The House passed the Sunshine Protection Act (H.R. 139) on July 14, 2026. It would make daylight time permanent, though states that already stay on standard time could keep doing so. The Senate referred it to committee on July 15, and as of late October 2026 it has not passed the Senate. The November 1 switch is going ahead.
Places that stay on CST all year
Several regions keep UTC-6 all year with no daylight time, so for them "UTC to CST" really is always minus 6 hours. A converter that assumes everyone in the Central zone switches will be an hour off for these places from March to November.
| Region | IANA zone | July offset | January offset |
|---|---|---|---|
| Chicago, Dallas, Winnipeg (US and Canada Central) | America/Chicago, America/Winnipeg |
UTC-5 (CDT) | UTC-6 (CST) |
| Most of Saskatchewan | America/Regina |
UTC-6 (CST) | UTC-6 (CST) |
| Mexico City, Monterrey, Guadalajara | America/Mexico_City, America/Monterrey |
UTC-6 (CST) | UTC-6 (CST) |
| Mexican border cities like Matamoros and Ojinaga | America/Matamoros, America/Ojinaga |
UTC-5 (CDT) | UTC-6 (CST) |
| Guatemala, Costa Rica, Belize, El Salvador, Honduras, Nicaragua | America/Guatemala, America/Costa_Rica, etc. |
UTC-6 (CST) | UTC-6 (CST) |
Mexico is the one that catches old systems. Its Ley de los Husos Horarios took effect on October 30, 2022 and ended daylight saving time, except for northern border municipalities that keep a seasonal schedule on the same dates as the US. A server or phone with tzdata from before late 2022 still moves Mexico City to UTC-5 every spring. If a Mexican customer reports that times are an hour off in summer, check the tzdata version before you check your code.
"CST" means three different time zones
CST is the abbreviation for US Central Standard Time (UTC-6), China Standard Time (UTC+8), and Cuba Standard Time (UTC-5). The IANA database uses that same label in all three places:
$ TZ=America/Chicago date -d '2026-01-15T14:00:00Z' '+%H:%M %Z %z'
08:00 CST -0600
$ TZ=Asia/Shanghai date -d '2026-01-15T14:00:00Z' '+%H:%M %Z %z'
22:00 CST +0800
$ TZ=America/Havana date -d '2026-01-15T14:00:00Z' '+%H:%M %Z %z'
09:00 CST -0500
China Standard Time and US Central Standard Time are 14 hours apart (13 while Chicago is on CDT). Any Linux server set to Asia/Shanghai prints CST in date output and in MySQL's @@system_time_zone. So if you are reading logs from a machine in China, "CST" in a timestamp almost certainly does not mean Chicago.
Java's own TimeZone documentation says it directly: three-letter IDs are deprecated because "CST" could be U.S. "Central Standard Time" and "China Standard Time", "and the Java platform can then only recognize one of them."
How runtimes read the string "CST"
When parsing a timestamp that ends in CST, different languages produce different UTC instants. Some treat the label as a fixed UTC-6 offset, some map it to the Chicago zone with daylight time, and Go's answer depends on the machine it runs on.
Here is one string, 2026-07-15 09:00:00 CST, parsed in each environment. Note that it is July, when real Chicago clocks say CDT, so the label itself is already suspicious. All tests ran on Ubuntu 24.04 with tzdata 2026e.
| Parser | UTC result | How it read "CST" |
|---|---|---|
Node.js 24 new Date(...) |
15:00 | Fixed UTC-6 |
PostgreSQL 18 timestamptz literal |
15:00 | Fixed UTC-6 (pg_timezone_abbrevs) |
Java 21 SimpleDateFormat |
15:00 | Fixed UTC-6 |
Java 21 DateTimeFormatter with z |
14:00 | Zone America/Chicago, so CDT applies |
Go 1.25 time.Parse, host in America/Chicago |
15:00 | Offset the local zone uses for CST |
Go 1.25 time.Parse, host in UTC |
09:00 | Unknown, so zero offset |
Go 1.25 time.Parse, host in Asia/Shanghai |
01:00 | China Standard Time, UTC+8 |
Four different answers to one question, spanning 14 hours. The Go behavior is documented: time.Parse uses an abbreviation's offset "if the zone abbreviation has a defined offset in the current location," and otherwise records the time "in a fabricated location with the given zone abbreviation and a zero offset." The same binary gives different results on a laptop in Chicago, a CI runner in UTC, and a server in Shanghai.
Using CST as a time zone name, rather than parsing it, is just as inconsistent:
| Setting | Result for 14:00 UTC on July 15 | Notes |
|---|---|---|
Python ZoneInfo("CST") |
ZoneInfoNotFoundError |
Not an IANA zone |
Go time.LoadLocation("CST") |
unknown time zone CST |
Not an IANA zone |
Java ZoneId.of("CST") |
ZoneRulesException |
Only works via ZoneId.SHORT_IDS, which maps to Chicago |
Node.js 24 timeZone: 'CST' |
9:00 AM CDT | ICU aliases it to America/Chicago |
PostgreSQL AT TIME ZONE 'CST' |
08:00 | Fixed UTC-6, an hour off in summer |
GNU date with TZ=CST |
14:00 CST | Treated as UTC but labeled CST |
The last row is the worst. glibc reads TZ=CST as a POSIX zone string with a name and no offset, so it uses UTC and prints the label CST. The output looks right and is 5 or 6 hours wrong. The legacy alias US/Central fails the same way on Ubuntu 24.04 unless the tzdata-legacy package is installed, except that the label comes out empty.
Unlike EST, there is no CST zone in the IANA database at all. The legacy POSIX-style name CST6CDT does exist and follows US rules correctly, but America/Chicago is the canonical choice.
The 13-hour bug: China time read as Chicago time
Software that writes a timestamp with a "CST" label in China and reads it back as US Central produces errors of 14 hours, or 13 during daylight time. In Java you can reproduce it in three lines:
var f = DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss z", Locale.US);
var shanghai = Instant.parse("2026-07-15T14:00:00Z").atZone(ZoneId.of("Asia/Shanghai"));
String s = shanghai.format(f); // "2026-07-15 22:00:00 CST"
ZonedDateTime.parse(s, f).toInstant(); // 2026-07-16T03:00:00Z, 13 hours late
Java formats Shanghai time with the label CST, then parses CST as America/Chicago. The round trip moves the instant by 13 hours.
A common version of this involves MySQL. A MySQL server on a machine set to Asia/Shanghai reports @@system_time_zone as CST. In bug #82192, filed in 2016, the reporter describes Connector/J resolving that label with TimeZone.getTimeZone(), getting US Central, and returning wrong timestamps. MySQL closed it as "not a bug" and suggested setting the server time zone property in the connection string. With current drivers that looks like this:
jdbc:mysql://db:3306/app?connectionTimeZone=Asia/Shanghai
Since Connector/J 8.0.23, the older serverTimezone property is an alias for connectionTimeZone, so existing URLs keep working.
The general fix is the same everywhere. Never store or exchange a timestamp with a three-letter label. Use an offset (2026-07-15T09:00:00-05:00), use UTC with a Z, or store UTC plus a separate IANA zone name if you need to know the user's local time later.
How to convert UTC to Central Time in code
To convert UTC to Central Time in code, mark the input as UTC explicitly, then convert to America/Chicago and let the time zone database pick CST or CDT for that date. If you need Saskatchewan or Mexico City, use their own zone names from the table above.
Python 3.9+
from datetime import datetime, timezone
from zoneinfo import ZoneInfo
utc = datetime(2026, 7, 15, 14, 0, tzinfo=timezone.utc)
print(utc.astimezone(ZoneInfo("America/Chicago")).strftime("%Y-%m-%d %H:%M %Z %z"))
# 2026-07-15 09:00 CDT -0500
JavaScript
new Date('2026-07-15T14:00:00Z').toLocaleString('en-US', {
timeZone: 'America/Chicago',
timeZoneName: 'short',
});
// '7/15/2026, 9:00:00 AM CDT'
Keep the Z. Without it, new Date() parses the string as the machine's local time.
Go
loc, _ := time.LoadLocation("America/Chicago")
t := time.Date(2026, 7, 15, 14, 0, 0, 0, time.UTC)
fmt.Println(t.In(loc).Format("2006-01-02 15:04 MST -0700"))
// 2026-07-15 09:00 CDT -0500
For parsing, use a layout with a numeric offset (-0700 or time.RFC3339) instead of MST, for the reasons in the table above.
Shell (GNU date)
TZ=America/Chicago date -d '2026-07-15T14:00:00Z' '+%F %T %Z'
# 2026-07-15 09:00:00 CDT
PostgreSQL
SELECT timestamptz '2026-07-15 14:00:00+00' AT TIME ZONE 'America/Chicago';
-- 2026-07-15 09:00:00
Write 'America/Chicago', not 'CST'. PostgreSQL treats the abbreviation as a fixed UTC-6 offset, which returns 08:00 for this July timestamp.
Checking a timestamp without pasting your logs into a website
For a one-off check, a local converter is quicker than writing a script, and you avoid pasting log lines (with hostnames, user IDs, and request paths) into a web form.
SelfDevKit's timestamp converter runs entirely on your machine. Paste a Unix timestamp in seconds or milliseconds, or an ISO 8601 string, and it shows the result in UTC, your local zone, and a set of common zones that includes both America/Chicago and Asia/Shanghai. Each row is labeled with its IANA zone name rather than a three-letter abbreviation, so the two CSTs never get mixed up. The Chicago row uses whatever offset applied on that date. Depending on your system locale it is shown as CDT/CST or GMT-5/GMT-6, while Shanghai is shown as GMT+8.
Include the Z when you paste an ISO string. 2026-07-15T14:00:00Z is an exact instant. Without the Z, the value is read as your own local time.
If your logs store epoch integers, the Unix timestamp converter guide explains seconds versus milliseconds, and convert Unix timestamp shows how to convert them in place inside SQL and log tools. If a scheduled job keeps running an hour early or late for Central users after each DST change, the cron and crontab guide covers CRON_TZ, and the cron job generator builds expressions offline.
Quick answers
Is CST UTC-6 or UTC-5?
CST is always UTC-6. In summer the US Central zone switches to CDT, which is UTC-5. People often say "CST" all year when they mean "Central Time"; the neutral abbreviation is "CT".
What is 12:00 UTC in CST?
6:00 AM CST in winter and 7:00 AM CDT in summer. In Saskatchewan, Mexico City, and most of Central America it is 6:00 AM all year.
How do I convert CST to UTC?
Add 6 hours to CST, or 5 to CDT. First confirm that "CST" means US Central. If the source was a server in China, add nothing and subtract 8 hours instead.
Try it yourself
SelfDevKit bundles the timestamp converter with JSON tools, a cron generator, and 50+ other developer utilities in one offline desktop app, so your production timestamps stay on your machine.
Download SelfDevKit to convert UTC to CST, Central Time, and any other zone in the list without opening a browser tab.
