How to customize the WordPress date format

Short answer: to change how dates look across your site, go to Settings > General and pick a date and time format, or type a custom one into the Custom field using PHP date characters – F j, Y gives May 21, 2026 , d/m/Y gives 21/05/2026 . That setting controls every date WordPress prints through its own templates. To format a date inside a theme template yourself, use wp_date() so the result respects the site’s timezone and language.

This guide covers the Settings screen, the PHP format characters you build custom formats from, formatting dates in template files the right way, and the timezone gotcha that trips up almost everyone the first time.

Changing the date format in Settings#

The site-wide format lives in Settings > General, near the bottom of the screen – sign in to the WordPress dashboard and open it from the left-hand menu. There are two groups of radio buttons:

• Date format – how dates appear (post dates, archive headings, comment dates).
• Time format – how times appear where a time is shown.

Each group offers a few presets plus a Custom radio button with a text field. The presets cover the common cases:

• F j, Y -> May 21, 2026
• Y-m-d -> 2026-05-21
• m/d/Y -> 05/21/2026
• d/m/Y -> 21/05/2026

Pick a preset, or select Custom and type your own string. WordPress shows a live preview of the current date next to the field, so you can see the result before saving. Scroll down and click Save changes.

One setting you should get right while you are on this screen is Timezone – choose your city or a UTC offset. It does not change how dates are formatted, but it does decide what “now” means, which matters for scheduled posts and for any date your templates calculate. More on that below.

PHP date format characters#

The custom format field is not free text – it is a string of PHP date characters, each of which stands for one piece of a date or time. WordPress passes your string to PHP’s date engine and substitutes each character for the real value.

These are the ones you will use most:

You combine them with any punctuation or spaces you like – those are printed literally. A few practical formats:

• l, F j, Y -> Thursday, May 21, 2026
• jS F Y -> 21st May 2026
• D, d M Y -> Thu, 21 May 2026
• g:i a -> 3:09 pm

If you need a literal letter that happens to be a format character – say the word “of” inside a date – escape it with a backslash: jS \o\f F Y produces 21st of May 2026 . Without the backslashes, the o and f would be read as format characters and give you the wrong output.

Formatting dates in theme templates#

Changing the Settings format updates every date WordPress prints on its own. But when you write a theme template, you decide how each date is formatted, and one common function is the wrong choice.

The function to reach for first is get_the_date() . Called with no argument, it returns the post’s date in the site-wide format you set in Settings – so it stays consistent with the rest of the site automatically:

echo get_the_date();

Pass it a format string when one specific spot needs a different look – a compact archive listing, for example:

echo get_the_date( 'M j' );

For a date that is not the post date – a custom field, a calculated value, today’s date in a footer – use wp_date() . This is the function that does the job correctly:

echo wp_date( 'F j, Y' );

wp_date() matters because it does two things the older functions do not:

• It applies the site’s timezone from Settings, so the result is the local date, not the server’s date.
• It translates month and weekday names into the site’s language. On a French site, wp_date( 'l' ) returns jeudi , not Thursday .

What to avoid is PHP’s plain date() function. date() knows nothing about WordPress – it uses the server’s timezone and always prints English. A footer that says echo date( 'Y' ); will quietly show the wrong year for a few hours each New Year’s Eve if your server runs on UTC and your site does not. Use wp_date( 'Y' ) instead. If all you need is the current year for something like a copyright line, the same idea applies whether you write it in a template or as a shortcode – see how to use WordPress shortcodes for the [current_year] pattern, and how to edit the footer in WordPress for where that output belongs.

The older date_i18n() function still works and is timezone-aware, but wp_date() superseded it in modern WordPress and is the function to use in new code.

The timezone gotcha#

This is the part that confuses people, and it is worth understanding once so it never confuses you again.

WordPress stores every date in your database in UTC. A post published at 3:00 pm in New York is saved as 19:00 (or 20:00 , depending on daylight saving). The local time you see in the admin and on the front end is calculated on the fly: WordPress takes the stored UTC value and shifts it by the offset of the timezone you picked in Settings > General.

That design is correct – it means your dates survive a server move and stay consistent for visitors. But it has consequences:

• If a post date looks hours off, the cause is almost always a wrong Timezone setting, not a wrong format. Fix it in Settings > General.
• In template code, never read a date with PHP’s date() or time() and assume it is local. Those give you UTC or the server timezone. Use wp_date() for output and current_time() when you need a WordPress-aware timestamp.
• Choose a named city (like “America/New_York”) over a fixed UTC offset. A named timezone handles daylight saving automatically; a fixed offset does not, so a UTC+1 site drifts an hour out twice a year.
• Scheduling a post uses the site timezone too. If posts publish an hour early or late, check the timezone before blaming the scheduler.

The short version: store and think in UTC, display in the site timezone, and let wp_date() do the conversion for you.

Per-post and locale considerations#

A few smaller points round this out:

• The format is site-wide, not per-post. There is no built-in setting to format one post’s date differently from another. If you genuinely need that, it is a template-level decision – check a category or custom field and call get_the_date() with a different string.
• Multilingual sites get translated month and weekday names for free as long as you format dates with wp_date() or get_the_date() . Hard-coded English from plain date() will not translate, which is another reason to avoid it.
• Block themes display post dates through the Post Date block. It follows the Settings format by default, and the block’s own settings let you override the format for that one block without touching code – useful when a single template part needs a different style.

Common mistakes to avoid#

• Using PHP date() in templates. It ignores the site timezone and language. Use wp_date() .
• Blaming the format for a wrong date. A date that is hours off is a timezone problem, not a format-string problem.
• Picking a fixed UTC offset instead of a city. Offsets do not follow daylight saving and drift twice a year.
• Forgetting to escape literal letters. An unescaped o or a in a custom format gets read as a format character. Escape literals with a backslash.
• Expecting per-post formatting from Settings. The General settings format is global; per-post differences are a template job.
• Editing template files directly in the parent theme. A theme update erases the change – make date-formatting edits in a child theme, the approach covered in how to create a custom WordPress theme from scratch.

How Hostney handles this#

Most of date formatting is a Settings screen and a few format characters – nothing platform-specific. Where Hostney helps is the timezone side and any template work you do.

Every Hostney site runs in its own isolated container with a current, correctly configured PHP environment, so wp_date() and current_time() behave exactly as the WordPress documentation describes – the server’s own clock is set to UTC, which is what WordPress expects underneath. That removes one common source of “the date is an hour off” reports: a misconfigured server timezone. The only timezone that matters for your site is the one you choose in Settings > General.

When you do need to edit a template – to add a date to a custom template part, or drop a wp_date() call into a child theme – you can reach the files through SSH/SFTP, FTPS, or the built-in file manager. The file manager’s code editor flags PHP syntax errors before you save, so a missing semicolon in a wp_date() call is caught before it can white-screen the site. If you are building a template part that prints a date, the same child-theme and asset patterns apply as in any theme work – see how to create a custom WordPress widget for where small bits of custom display logic belong.

Summary#

WordPress date formatting starts at Settings > General, where a date format string built from PHP date characters – F j, Y , d/m/Y , and so on – controls every date the site prints. In template code, use get_the_date() for the post date and wp_date() for any other date, because wp_date() applies the site’s timezone and language while plain PHP date() does neither. The one idea to keep is the storage model: WordPress saves dates in UTC and converts to your chosen timezone for display, so a date that looks wrong is almost always a timezone setting to fix, not a format string. Pick a named city for the timezone, format with wp_date() , and your dates stay correct and consistent everywhere.