How to Set the Date and Time From the macOS Command Line

On macOS, you set the system clock from the command line with the BSD date command and a bare numeric argument:

# Set the clock to 2026-06-14, 12:00:
sudo date 0614120026

That is it. The number is MMDDhhmm[[CC]YY][.ss]: two digits each of month, day, hour (24-hour), and minute, then an optional year, then optional seconds. No flags, no separators. You need sudo because the system clock is root-owned.

The reason this article exists is that the most-copied answer on the internet is wrong. You will see sudo date -I 06142024 passed around as the way to set the date on a Mac. It is not. -I is GNU coreutils' ISO-8601 output flag, it has nothing to do with setting anything, and BSD date (which is what ships on macOS) does not accept it that way. Run it and you get an error or a misread argument, never the clock you wanted. Below is the correct form, field by field, plus the one step everyone forgets: turning off network time first, or macOS quietly puts the clock back where it was.

The BSD date set syntax, field by field

macOS uses the BSD userland, so date is the BSD utility, not GNU coreutils. Its full set form is a single positional number. The man page writes it as:

sudo date [[[mm]dd]HH]MM[[cc]yy][.ss]

Read left to right, the eight common digits spell out MMDDhhmm:

Strictly speaking, the only mandatory field is the minutes (the man synopsis nests every field to the left of MM as optional: [[[mm]dd]HH]MM), and the century, year, and seconds on the right are optional too. In practice you almost always type the full MMDDhhmm block plus a year, because setting the minute alone (sudo date 30) just moves the clock to minute 30 of the current hour, which is rarely what you want. Any field you omit defaults to its current value. So a worked example for June 14, 2026 at 12:00:30:

sudo date 0614120026         # MMDDhhmm + YY  (year shorthand: 26)
sudo date 061412002026       # MMDDhhmm + CCYY (full year: 2026)
sudo date 061412002026.30    # ...with seconds (.30)

If you drop the year entirely (sudo date 06141200) the command keeps the current year and just changes the month, day, hour, and minute. To read the clock without touching it, run date with no argument and no sudo.

A common stumble: the field order is month first, then day, not day-month. 0614 is June 14, not the 6th of the 14th month. If you are coming from a DD/MM locale, that flip is the first thing to double-check.

Why date -I does not set anything

This is the wrong-source correction worth internalising. The -I form circulates because Linux examples leak onto Mac how-tos, and the two date commands are not the same program:

• GNU date (Linux) uses -d/--date and -s/--set to interpret and set time, and -I/--iso-8601 to print the date in ISO-8601 format. -I is an output formatter. It never sets the clock, even on Linux.
• BSD date (macOS) sets the clock with the bare MMDDhhmm[[CC]YY] string shown above. It has no --set flag and no GNU-style -I ISO option, so sudo date -I 06142024 either errors on the unknown option or misparses the trailing number. Nothing gets set.

If you genuinely want GNU date semantics on a Mac (the -d "next friday" style parsing, --iso-8601 output, and so on), install coreutils and use gdate:

brew install coreutils
gdate -d "2026-06-14 12:00" "+%Y-%m-%d %H:%M"   # GNU date, prefixed g

Reach for gdate for the parsing and formatting that people actually want -I for. To actually move the macOS system clock, stick with the BSD sudo date MMDDhhmm… form above: it is the documented, dependable way on macOS, where the BSD date is what the OS ships and supports.

Turn off network time first, or macOS resyncs

Here is the step that makes manual setting look broken when you skip it. By default macOS keeps the clock synced over the network (NTP), so the moment you set the date by hand, the time service notices the drift and silently corrects it back. Your sudo date worked; the OS just undid it seconds later.

Disable automatic network time before you set the clock:

sudo systemsetup -setusingnetworktime off
sudo date 0614120026

Check the current setting any time with sudo systemsetup -getusingnetworktime. While network time is off the clock holds whatever you set, which is exactly what you want for testing.

When you are done, turn it back on and macOS resyncs to the correct real time immediately:

sudo systemsetup -setusingnetworktime on

That resync is the clean reset: you do not have to figure out the right current time by hand, the time service does it for you. If you want a one-shot correction without toggling the setting, use sntp instead, which is the NTP client macOS ships (it replaced ntpdate, removed back in macOS 10.14 Mojave):

sudo sntp -sS time.apple.com

On the macOS build, -s slews the clock with adjtime(2) when the offset is small (under 50 ms) and -S steps it with clock_settime(2) when the offset is larger, so passing both lets sntp pick the right correction for the size of the drift; time.apple.com is Apple's own NTP host. This pulls the real time once and leaves the network-time setting where it was.

While you are in systemsetup, sudo systemsetup -settimezone "America/New_York" sets the timezone (list valid zones with sudo systemsetup -listtimezones), which is a separate concern from the clock value but often comes up in the same breath.

The actual use case: testing date-based logic

Almost nobody sets the Mac clock because they think it is wrong. They set it to test code that behaves differently on a certain date: a subscription that expires, a coupon that activates next week, a cron-style job, a "your trial ends in 3 days" banner, a certificate that goes stale. Moving the system clock forward is the brute-force way to see that path fire.

The brute-force way has a cost, though: every other app on the machine now thinks it is a different day, your TLS handshakes may fail, and if you forget to turn network time back on you are debugging a "wrong clock" for the rest of the afternoon. So the disciplined version is: turn network time off, set the date, run your test, turn network time back on. Keep that loop tight.

If you find yourself doing this often, a tool like libfaketime is worth a look: it intercepts time calls for a single process rather than moving the whole machine's clock, so you never touch the real system time at all. That is the cleaner long-term answer for repeatable date-based tests, while sudo date is the quick one-off.

See also

• Verify a file checksum on macOS: another BSD-vs-GNU tooling gotcha, shasum and md5 instead of md5sum.
• View your calendar and events from the macOS command line: cal, ncal, and icalBuddy once the clock is sorted.
• Open apps, files, and URLs from the macOS command line: the open command, another small BSD-only Terminal tool worth knowing.