Stay organized with collections
Save and categorize content based on your preferences.
Expressing dates and times in a clear and unambiguous way helps support
writing for a global audience and reduces
confusion.
Express times
In general, use the following guidelines to format expressions of time:
Use the 12-hour clock, except if required to use a 24-hour time, such as
when documenting features that use 24-hour time. If the UI, a command, or a code sample uses the
24-hour format, use that format throughout the page for consistency.
Use exact times when possible, but noon and midnight are OK.
Use hyphens in time ranges. Don't add spaces before or after the hyphens.
Recommended: 5-10 minutes ago.
Capitalize AM and PM, and leave one space between it and the time.
Recommended: 3:45 PM.
Remove the minutes from round hours.
Recommended: 3 PM.
Express time zones
Avoid using time zones unless absolutely necessary. In cases where you need to use a time
zone—such as describing real events at real times—use the following guidelines:
Let the reader know if the time is local to their time—for example, 10 AM your local
time.
If a time zone is necessary, use the timestamp format as seen in the user interface (if
available).
If using a specific time zone, spell out the region and include the
UTC or GMT label
as a parenthetical. For example:
US and Canadian Pacific Standard Time (UTC-8)
US and Canadian Pacific Daylight Time (UTC-7)
Don't abbreviate the name of the time zone.
In the rare event where the time of an event doesn't change for daylight saving time, use the
specific time zone, without reference to UTC.
Express dates
In general, spell out the names of months and days of the week in full. Give
the full four-digit year, not a two-digit abbreviation.
Recommended: January 19, 2017
If including the day of the week, add it before the month as follows:
DAY_OF_WEEK, MONTHDAY,
YEAR.
Recommended: Tuesday, April 27, 2021
Partial dates and abbreviations
When giving only the month and year, don't use a comma.
Recommended: She was hired in January
2017.
In most cases, don't abbreviate the day of the week or the month. However,
when conserving space, such as in a heading or table, it's okay to abbreviate
the month and the day of the week to their three-letter abbreviations.
Capitalize the first letter and do not add a period at the end of the abbreviation.
If you abbreviate, do so for the entire date. Don't mix written-out forms with
abbreviated forms in the same date.
Be consistent in where you apply abbreviations throughout your documentation. For
example, if you choose to abbreviate in table cells, do so in all table cells.
Recommended: Mon, Sep 3, 2018
Not recommended: Mon, September 3, 2018
Dates in the middle of a sentence
When a MONTHDAY, YEAR
date appears in the middle of a sentence, add a comma after the year.
Recommended: The January 19, 2017,
release of ...
However, if the date in the middle of the sentence consists of the
month and year only, don't use a comma.
Recommended: The January 2017 release
of ...
Why we prefer dates written out
In general, don't express months as numbers unless you don't have the option
(in which case, see numeric-only date
format). Different regions of the world put parts of the date in a different
order for numeric dates. For example, a date written as 04/05/09 means different
things in different regions:
In the UK, 04/05/09 means May 4, 2009, where the order is usually day,
month, and then year.
In the US, 04/05/09 means April 5, 2009, where the order is usually month,
day, and then year.
In some other parts of the world, 04/05/09 means May 9, 2004. Some
regions write the year first, followed by the month and day.
For this reason, we recommend always using words to express dates. Expressing
dates in numbers only (using slashes, periods, or hyphens as separators) can be
confusing.
Recommended: February 12, 2017
Recommended: Sunday, February 12, 2017
Not recommended: 02.12.2017
Not recommended: 12/02/2017
Numeric-only date format
If you must express a date in numerical date format, use the format
YYYY-MM-DD, and separate the elements by using hyphens. This conforms
to ISO 8601 international
standards for numerical date format.
Additionally, if you have a choice of what date to write (such as in a
fictional example), then choose a calendar day greater than 12 to differentiate
it from the month.
Recommended: 2017-04-15
Not recommended: 04/06/2017
Express dates and times together
If you must express a date and a time together, then mention the date first and then the time.
Recommended: 2017-04-15 at 3 PM
Recommended: May 4, 2009, at 6 PM
Express divisions of the year
Avoid referring to seasons. Spring in the northern hemisphere is fall (autumn) in the
southern hemisphere. Instead, use the month, quarter, or temperature (if relevant).
Recommended
Not recommended
During warmer months, data centers face a higher risk of cooling failures.
During summer months, data centers face a higher risk of cooling failures.
In November and December, data centers experience higher traffic volume.
In winter, data centers experience higher traffic volume.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Missing the information I need","missingTheInformationINeed","thumb-down"],["Too complicated / too many steps","tooComplicatedTooManySteps","thumb-down"],["Out of date","outOfDate","thumb-down"],["Samples / code issue","samplesCodeIssue","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2024-10-15 UTC."],[[["\u003cp\u003eExpress dates with the full month name, day, and four-digit year, for example, January 19, 2017.\u003c/p\u003e\n"],["\u003cp\u003eExpress time using the 12-hour clock with AM or PM, omitting minutes for round hours, for example, 3 PM.\u003c/p\u003e\n"],["\u003cp\u003eAvoid using time zones unless necessary; if needed, use the full region name and UTC offset, such as US and Canadian Pacific Standard Time (UTC-8).\u003c/p\u003e\n"],["\u003cp\u003eFor numeric-only dates, adhere to the ISO 8601 standard (YYYY-MM-DD), like 2017-04-15.\u003c/p\u003e\n"],["\u003cp\u003eAvoid using seasons; instead, specify months or quarters for clarity in global content.\u003c/p\u003e\n"]]],["For clarity, express times using the 12-hour clock (unless 24-hour is required for consistency), capitalize AM/PM with a space, and use hyphens in time ranges. When necessary, indicate time zones using the full region name and UTC/GMT label. Spell out dates fully (e.g., January 19, 2017), and include the day of the week before the month. Use the format YYYY-MM-DD for numerical dates and avoid using seasons.\n"],null,["Expressing dates and times in a clear and unambiguous way helps support\n[writing for a global audience](/style/translation) and reduces\nconfusion.\n\nExpress times\n\nIn general, use the following guidelines to format expressions of time:\n\n- Use the 12-hour clock, except if required to use a 24-hour time, such as when documenting features that use 24-hour time. If the UI, a command, or a code sample uses the 24-hour format, use that format throughout the page for consistency.\n- Use exact times when possible, but *noon* and *midnight* are OK.\n- Use hyphens in time ranges. Don't add spaces before or after the hyphens.\n\n Recommended: 5-10 minutes ago.\n- Capitalize AM and PM, and leave one space between it and the time.\n\n Recommended: 3:45 PM.\n- Remove the minutes from round hours.\n\n Recommended: 3 PM.\n\nExpress time zones\n\nAvoid using time zones unless absolutely necessary. In cases where you need to use a time\nzone---such as describing real events at real times---use the following guidelines:\n\n- Let the reader know if the time is local to their time---for example, *10 AM your local\n time*.\n- If a time zone is necessary, use the timestamp format as seen in the user interface (if available).\n- If using a specific time zone, spell out the region and include the [UTC or GMT label](https://www.worldtimeserver.com/learn/utc-vs-gmt/) as a parenthetical. For example:\n - US and Canadian Pacific Standard Time (UTC-8)\n - US and Canadian Pacific Daylight Time (UTC-7)\n- Don't abbreviate the name of the time zone.\n- In the rare event where the time of an event doesn't change for daylight saving time, use the specific time zone, without reference to UTC.\n\nExpress dates\n\nIn general, spell out the names of months and days of the week in full. Give\nthe full four-digit year, not a two-digit abbreviation.\n\nRecommended: January 19, 2017\n\nIf including the day of the week, add it before the month as follows:\n\u003cvar translate=\"no\"\u003eDAY_OF_WEEK\u003c/var\u003e, \u003cvar translate=\"no\"\u003eMONTH\u003c/var\u003e \u003cvar translate=\"no\"\u003eDAY\u003c/var\u003e,\n\u003cvar translate=\"no\"\u003eYEAR\u003c/var\u003e.\n\nRecommended: Tuesday, April 27, 2021\n\nPartial dates and abbreviations\n\nWhen giving only the month and year, don't use a comma.\n\nRecommended: She was hired in January\n2017.\n\nIn most cases, don't abbreviate the day of the week or the month. However,\nwhen conserving space, such as in a heading or table, it's okay to abbreviate\nthe month and the day of the week to their three-letter abbreviations.\nCapitalize the first letter and do not add a period at the end of the abbreviation.\n\nIf you abbreviate, do so for the entire date. Don't mix written-out forms with\nabbreviated forms in the same date.\n\n\nBe consistent in where you apply abbreviations throughout your documentation. For\nexample, if you choose to abbreviate in table cells, do so in all table cells.\n\nRecommended: Mon, Sep 3, 2018\n\nNot recommended: Mon, September 3, 2018\n\nDates in the middle of a sentence\n\nWhen a \u003cvar translate=\"no\"\u003eMONTH\u003c/var\u003e \u003cvar translate=\"no\"\u003eDAY\u003c/var\u003e, \u003cvar translate=\"no\"\u003eYEAR\u003c/var\u003e\ndate appears in the middle of a sentence, add a comma after the year.\n\nRecommended: The January 19, 2017,\nrelease of ...\n\nHowever, if the date in the middle of the sentence consists of the\nmonth and year only, don't use a comma.\n\nRecommended: The January 2017 release\nof ...\n\nWhy we prefer dates written out\n\nIn general, don't express months as numbers unless you don't have the option\n(in which case, see [numeric-only date\nformat](#numeric-only-date-format)). Different regions of the world put parts of the date in a different\norder for numeric dates. For example, a date written as 04/05/09 means different\nthings in different regions:\n\n- In the UK, 04/05/09 means May 4, 2009, where the order is usually day, month, and then year.\n- In the US, 04/05/09 means April 5, 2009, where the order is usually month, day, and then year.\n- In some other parts of the world, 04/05/09 means May 9, 2004. Some regions write the year first, followed by the month and day.\n\nFor this reason, we recommend always using words to express dates. Expressing\ndates in numbers only (using slashes, periods, or hyphens as separators) can be\nconfusing.\n\nRecommended: February 12, 2017\n\nRecommended: Sunday, February 12, 2017\n\nNot recommended: 02.12.2017\n\nNot recommended: 12/02/2017\n\nNumeric-only date format\n\nIf you must express a date in numerical date format, use the format\n\u003cvar translate=\"no\"\u003eYYYY-MM-DD\u003c/var\u003e, and separate the elements by using hyphens. This conforms\nto [ISO 8601 international\nstandards](https://wikipedia.org/wiki/ISO_8601) for numerical date format.\n\nAdditionally, if you have a choice of what date to write (such as in a\nfictional example), then choose a calendar day greater than 12 to differentiate\nit from the month.\n\nRecommended: 2017-04-15\n\nNot recommended: 04/06/2017\n\nExpress dates and times together\n\nIf you must express a date and a time together, then mention the date first and then the time.\n\nRecommended: 2017-04-15 at 3 PM\n\nRecommended: May 4, 2009, at 6 PM\n\nExpress divisions of the year\n\nAvoid referring to seasons. Spring in the northern hemisphere is fall (autumn) in the\nsouthern hemisphere. Instead, use the month, quarter, or temperature (if relevant).\n\n| Recommended | Not recommended |\n|----------------------------------------------------------------------------|----------------------------------------------------------------------------|\n| During warmer months, data centers face a higher risk of cooling failures. | During summer months, data centers face a higher risk of cooling failures. |\n| In November and December, data centers experience higher traffic volume. | In winter, data centers experience higher traffic volume. |\n| Changes are released in October of each year. | Changes are released in the Fall of each year. |"]]
