Dates appear throughout a WordPress site — post publish dates, modified dates, comment timestamps, event listings, and dynamic copyright notices. The default date format may show “July 4, 2025” when the site’s audience expects “04/07/2025” or “4 juli 2025” or “2025年7月4日”. WordPress date format configuration controls how dates display across the entire site, and understanding the format string syntax unlocks complete control over every date and time display. For the bigger picture, our Complete Guide to WordPress How pulls everything together.
WordPress Date Format — Settings and Configuration
The global WordPress date format is set in Settings → General → Date Format. WordPress provides four preset options plus a Custom field: “F j, Y” produces “July 4, 2025”; “Y-m-d” produces “2025-07-04” (ISO 8601 format); “m/d/Y” produces “07/04/2025” (US format); “d/m/Y” produces “04/07/2025” (European format). The Custom field accepts any combination of PHP date format characters to produce exactly the format required.
The WordPress date format Custom field uses PHP’s date() function format characters. The most commonly used characters: Y (4-digit year, e.g., 2025), y (2-digit year, e.g., 25), m (2-digit month, 01–12), n (month without leading zero, 1–12), M (3-letter month abbreviation, Jan–Dec), F (full month name, January–December), d (2-digit day, 01–31), j (day without leading zero, 1–31), D (3-letter day name, Mon–Sun), l (full day name, Monday–Sunday). Separators between components can be any character: hyphens (-), slashes (/), dots (.), spaces, or any text literal. Literal text in the date format must be escaped with backslashes: \o\n F j, Y produces “on July 4, 2025” — the backslash-o and backslash-n prevent o and n from being interpreted as format characters (o = ISO week year, n = month number).
The time format at Settings → General → Time Format controls how times display alongside dates. Default options: “g:i a” produces “3:04 pm” (12-hour with lowercase am/pm), “g:i A” produces “3:04 PM” (12-hour with uppercase AM/PM), “H:i” produces “15:04” (24-hour format). The WordPress date format and time format work together when template tags output both: the_date() . ' at ' . the_time() uses both format settings to produce “July 4, 2025 at 3:04 pm.” According to the WordPress developer documentation, the date and time format settings in Settings → General apply site-wide as defaults, but individual template tags and template functions can accept a format parameter that overrides the global setting for specific display contexts — allowing different formats in different parts of the site without changing the global default.
Using Date Format Template Tags
WordPress template tags for displaying dates give developers fine-grained control over WordPress date format output in theme templates and plugin code, independent of the global settings.
Core date template tags: the_date($format) outputs the post’s publish date (echoes directly). get_the_date($format) returns the publish date as a string. the_modified_date($format) outputs when the post was last modified. the_time($format) outputs the time. get_the_time($format) returns the time as a string. All $format parameters accept the same PHP date format characters as the Settings field. Passing an empty string or omitting the parameter uses the global Settings format.
Custom date formatting in template code uses the WordPress date format character set with any combination: echo get_the_date('D, d M Y'); produces “Thu, 04 Jul 2025”. For relative dates (“3 days ago”, “2 weeks ago”), use the human_time_diff() function: echo human_time_diff(get_the_time('U'), current_time('timestamp')) . ' ago';. Relative dates are more reader-friendly for recent posts on news sites and blogs — displaying “2 hours ago” rather than a specific timestamp makes the content feel more timely. For archives and sitemap contexts where specific dates are important for context, the absolute WordPress date format is more appropriate than relative times. Our guide on WordPress template tags covers the full range of date and time template tags alongside all other post metadata template functions — the date tags are among the most frequently used in theme development and work identically to the other metadata functions in terms of echo versus return variants and parameter handling.
Date Format for Multilingual and International Sites
International WordPress sites need WordPress date format configurations that match each language and locale’s conventions — Japanese dates put the year first, European dates put the day first, and some languages use entirely different month names or calendar systems.
WordPress translates month and day names automatically when the site language is set: Settings → General → Site Language. With a French locale, F (full month name) outputs “juillet” instead of “July”, and l (day name) outputs “jeudi” instead of “Thursday”. The format string Y-F-j with a French locale produces “2025-juillet-4” — WordPress handles the translation of translatable components while preserving the format structure. The numeric format characters (m, d, Y) are not translated — only the alphabetic name characters (F, M, l, D) change with the locale.
For sites using WPML or Polylang with multiple active languages, the WordPress date format may need to be different per language — some languages use different calendar conventions, separator characters, or component orders. The date_i18n() function (WordPress’s internationalised date function) handles locale-aware date formatting: echo date_i18n('j. F Y', get_the_time('U')); — with a German locale this produces “4. Juli 2025” with the German month name and the period separator convention. Filter the date format per language: add_filter('date_format', function($format) { if (apply_filters('wpml_current_language', NULL) === 'de') { return 'j. F Y'; } return $format; }); — this applies a German-specific date format for German pages while using the default format for all other languages. Using date_i18n() rather than PHP’s date() function in theme templates ensures locale-aware WordPress date format output that automatically adapts to the current language without any additional conditional logic for each locale. Our guide on setting up WordPress translation covers the multilingual configuration that determines which locale date_i18n() uses for each visitor’s language, providing the locale context that makes the date format adaptation automatic.
Changing Date Format Without Affecting URLs
WordPress URLs can include the date using the date-based permalink structure (/2025/07/04/post-slug/) — but the WordPress date format setting in Settings → General affects only the visual display of dates in content, not the URL format. The permalink structure is configured separately at Settings → Permalinks.
If the site is switching from a date-based permalink structure to a non-date structure (a common migration for improved SEO), the visual WordPress date format in content is not affected — only the URLs change. However, the URL change requires 301 redirects from the old date-based URLs to the new clean URLs to preserve SEO equity. The Redirection plugin or Rank Math’s redirect manager handles these URL redirects, and the old date-based URLs should redirect within 24 hours of the permalink change to prevent search engines from seeing 404 errors at previously indexed URLs.
Displaying the current year dynamically (for copyright notices, “Updated for [year]” notices, or time-sensitive content headers) uses PHP’s date function in theme templates or a shortcode: add_shortcode('current_year', function() { return date('Y'); }); — using [current_year] in any content automatically shows the current year, updating automatically on January 1 without any manual content edits. This is significantly more maintainable than manually updating footer copyright years or article freshness notices each January. The shortcode approach works in posts, pages, widgets, and anywhere WordPress processes shortcodes — a single registration in functions.php enables the dynamic year display everywhere. Reviews from the WordPress developer community confirm that date_i18n() is the correct function for all locale-aware WordPress date format output in themes and plugins, as it handles both the format string interpretation and the translation of month and day names for the current locale, ensuring consistent and correct date display across all languages and regions served by the WordPress installation.
Schema Markup and Machine-Readable Dates
WordPress date format for human-readable display and schema markup dates for machine reading serve different purposes and should use different format characters. Schema.org’s datePublished and dateModified properties require ISO 8601 format (YYYY-MM-DD or YYYY-MM-DDThh:mm:ss+00:00) — not the human-readable format configured in Settings → General.
Output schema-compliant dates in structured data: get_the_date('c'); — the ‘c’ format character in PHP produces a full ISO 8601 timestamp including timezone offset, suitable for schema.org datePublished values. Rank Math and Yoast SEO both output schema-compliant dates automatically in their JSON-LD structured data output — if using either plugin, no custom code is needed for schema dates. For custom schema implementations: <meta property="article:published_time" content="<?php echo esc_attr(get_the_date('c')); ?>"> outputs the Open Graph publish time with the correct machine-readable format.
The difference between the human-readable WordPress date format and the schema date format matters for search engine rich results — Google’s FAQ page rich results and Article schema require ISO 8601 dates in the datePublished field. A human-readable date (“July 4, 2025”) in a schema field that expects ISO 8601 (“2025-07-04T09:30:00+00:00”) is technically invalid and may not be parsed correctly by search engines, potentially preventing rich result eligibility for that content. Always use the ‘c’ or ‘Y-m-dTH:i:s’ format characters for machine-readable date output in schema markup, meta tags, and API responses, while using the human-friendly format characters (F j, Y or d/m/Y as appropriate) for visible date display in post headers, bylines, and archive listings. This dual-format approach — human readable for visitors, ISO 8601 for machines — is the standard that Rank Math, Yoast, and all well-written WordPress themes implement for comprehensive WordPress date format correctness across all date display contexts on the site.
The WordPress date format string used in Settings → General also affects the REST API’s date output in some contexts — specifically the date field returned by the /wp-json/wp/v2/posts endpoint uses ISO 8601 regardless of the Settings format, but custom fields that store and display dates formatted using the global format setting will reflect the Settings value. For headless WordPress applications that fetch post data through the REST API, use the date_gmt and modified_gmt fields which always return UTC ISO 8601 format — these are consistent and unaffected by the Settings → General format string, making them more reliable for programmatic date handling in JavaScript and other languages than the formatted date fields that reflect the admin’s human-readable format choice.
Caching considerations for dynamic WordPress date format elements: page caches store a static HTML snapshot of the page at generation time. A “last updated” timestamp that should show the current time will show the cached generation time instead — potentially hours or days old depending on cache TTL. For date displays that must be current (article freshness indicators, live countdown timers, real-time published-time displays), use JavaScript with the HTML time element’s datetime attribute as the machine-readable source: <time datetime="<?php echo esc_attr(get_the_date('c')); ?>" class="dynamic-date"></time> and JavaScript reads the datetime attribute (always the correct ISO 8601 time from the server) and formats it client-side with the user’s local timezone and locale preferences. This approach produces correctly localised WordPress date format output (the user’s own browser formats the date according to their locale setting) while being cache-friendly since the machine-readable datetime attribute never needs to change and the human-readable output is generated dynamically by the visitor’s browser.
Post expiry and date-based visibility using WordPress date format conditional logic creates content that automatically changes or hides based on dates. A common pattern for time-limited offers: store an expiry date in post meta → in the template, compare the current date against the expiry date → conditionally display a countdown or hide the offer after expiry. Use WordPress’s current_time(‘timestamp’) function rather than PHP’s time() for the current time to ensure timezone consistency with how WordPress stores dates — WordPress stores times in GMT in the database but current_time() returns the site’s local time accounting for the timezone setting in Settings → General. Mixing PHP’s time() and WordPress’s date storage times produces off-by-hours errors equal to the site’s UTC offset. The WordPress date format timezone setting (Settings → General → Timezone) affects not just how dates display but how date comparisons work in PHP code — always use WordPress’s time functions rather than PHP’s native functions when comparing dates stored in the WordPress database to avoid timezone-related logic errors.
Testing a new WordPress date format before applying it site-wide is straightforward using the live preview in Settings → General — clicking any of the preset format radio buttons or typing in the Custom field immediately shows a preview of how the current date renders in that format, directly below the field. This instant preview prevents the common mistake of misremembering PHP date format characters and accidentally publishing a date format that shows “Fj Y” as literal text rather than “July 4 2025” because the space between F and j was omitted (the format string needs F j, Y with the space between F and j). After confirming the format in the preview, save and verify on the actual published site that the format appears correctly in post bylines, archive listings, and any other places the site displays dates — some themes use custom date formatting that overrides the Settings format for specific display contexts, making a full-site visual check the definitive confirmation of correct WordPress date format implementation across all templates. Related: WordPress Author Archive.
