Date/Time names is required topic to work in Date/Time Patterns.
Certain calendar fields can have both numeric and textual forms. Textual forms are things like months of the year (January, February, etc..) and days of the week (Sunday, Monday, etc..)
This text forms can vary in length
Wide (e.g. Sunday)
Abbreviated (e.g Sun)
Narrow (e.g. S)
There are two styles. For more information, see When to use standalone vs. formatting in Date/Time patterns.
Formatting
Standalone
Capitalization should follow the middle of a sentence rule. For more information, see Capitalization.
<contextTransforms> data can specify the capitalization for other contexts; currently this is not available in the Survey Tool, so you must file a CLDR JIRA ticket to request a change.
Most sets of names form Logical Groups, and you need to make sure they have the same contribution status (e.g. Status: Approved) or you will get error messages. See Logical Groups for more information.
The date field names are used in user interfaces on computer systems as labels as shown in this table example, where a user is asked to enter the year, month, and day:
Year
Month
Day
1942
...
...
The grammatical form should be whatever is typical for such isolated or stand-alone cases: generally it will be nominative singular. The letter casing should be appropriate for middle-of-sentence use, since there is now separate capitalization context data that can specify how these should be capitalized for use in a label. Also see the translation guide on Capitalization.
There are three lengths: full, short, and narrow. They are listed below along with English examples and explanations (a few of the fields are not straightforward).
Era names are in Gregorian Calendar and other calendars:
There are only two values for an era in a Gregorian calendar.
The common use of these era names in English are more for religious forms. "BC" (Before Christ) and AD (Anno Domini)" - from the Latin for "The year of our Lord".
The secular equivalents of these two era names are "BCE" (Before Common Era) and "CE" (Common Era).
Other calendars (see Different calendars in Date/Time patterns) have a different numbers of eras.
The names for eras are often specific to the given calendar, such as the Japanese era names.
If other calendars are in common use in one of the countries/regions that use your language, other calendars will show under the modern coverage level.
💡 Translation Tips
For Gregorian Calendar you will need to consider whether the religious (BC/AD) form or the secular (BCE/CE) form is more commonly used in your language, and make the most common form the default form (code 0, 1).
The alternate form, if used, can be provide under the entries for codes 0-variant, 1-variant. If your locale does not commonly use an alternate form, do not provide any entries for these.
In the Gregorian calendar, these designate the four three-month periods often used for financial reporting. The abbreviated or narrow forms may simply be something like “Q2” or “2” respectively. These may not be useful in calendars that do not always have 12 months in a year.
This field is one of the months of the year, such as January or February.
In many languages, it is not common to use abbreviated months. The preferred way to address this is using date/time patterns that never use the abbreviated months MMM or LLL, as explained in Patterns without abbreviated months.
💡 Translation Tips
If there is no way to supply abbreviated month names, the full month names may be used for abbreviated month names.
Use grammatical form such as genitive or related for Formatting month names if applicable in your language.
Used in patterns with a day number. (e.g. Finnish, and many Slavic languages distinguish between nominative and genitive/related)
Use the type such as the nominative case for Standalone month names.
Used in pattern without a day number.
The specific values that are used in the format and stand-alone names need to be closely co-ordinated with the date patterns that will use them. See When to use standalone vs. format names in Date/Time patterns.
Some languages (for example, Catalan) use a preposition to combine the month and day number like in the format “11 de setembre” (11 of September). If the month name begins with a vowel, the preposition is contracted, for example, “12 d’octubre
Include the preposition in its correct form (contracted or not) for formatting month names
DO NOT include the preposition for standalone month names and in patterns that use standalone month names
This field is one of the days of the week: Monday, Tuesday, Wednesday, etc...
Same as month names, you need to use different symbols to coordinate use of standalone (e.g. cccc) and format names (e.g. EEEE) in patterns. See When to use standalone vs. format names in Date/Time patterns.
💡 Translation Tips
The formatting vs standalone guidance also applies to days of the week:
Formatting names: Use the type such as genitive or related
Standalone names: Use the nominative case
AM/PM (special handling for locales using 24 hrs)
Also see Additional Date/time formats.
💡 Translation Tips
For locales using the 24 hr as the standard formats, AM/PM data fields are difficult to handle.
There may be codes that may have no English equivalent.
For example, Malayalam has the code morning2, which doesn’t exist in English.
The goal is to make sure that the abbreviated format and abbreviated standalone forms are correct.
Start with the Wide forms, then the abbreviated forms, then the narrow forms. You will see the inheritance option (the abbreviated form) will be available in the Others column.
The time span associated with each code is different for different languages!
To see what the time-spans are for your language, hover over the value.
You should see something like the following:
It shows the time span (with a 24 hour clock) for the code, and then an example (for the format codes).
You can also go to the web page Day Periods, and look for your language.
For example, for Malayalam, you would go to ...day_periods.html#ml , and see that morning2 is the period that extends from 06:00 to 12:00.
The format version will be substituted into a time format, and should contain whatever inflections/prepositions are necessary for that.
For example:
DayPeriods are spans of time during the day. There are two forms for each possible period:
stand-alone: used to label a particular period, such as "morning".
format: used in combination with a specific time, such as "12 noon" or "7 in the morning".
The codes may also be used—like plural categories—to select messages based on the day period. For example, an email program might use them to select among messages like: "arrived last night" or "arrived this morning".
In all of the Span examples below, the times are 24 hour starting at 00:00 (midnight). The span does not actually include the second number of the range. For example, 05:00-08:00 is really 05:00-07:59:59.999...
There are two types of day periods, fixed and locale-specific.
The fixed periods have the same definition in each language. The codes am and pm must always exist, even if your language always uses 24 hour time and doesn't use am/pm in any patterns (they are required for testing). So use the best term you can. As long as the 24 hour symbol (H) is used in the patterns, they won't actually show up in formatted times and dates.
Noon or midnight don't have to be present if the precise terms don't exist in your language. For example, many languages don't have a special term for precisely 12:00 noon. They may have a term for "midday" that spans from (say) 11:00-13:00, but not have unique term for exactly 12:00 noon or a noon hour. Such a language should not have a code for noon show up in the Survey Tool.
In formatting, where your language has a term for midnight, it is used instead of the term for am for the point in time 00:00 (= 24:00) when the pattern uses ‘b’ instead of ‘a’. Similarly, where your language has a term for noon, it is used instead of pm for the point in time 12:00 when the pattern uses ‘b’.
These mark approximate periods in the day, and those periods differ between languages. The codes are arbitrary, and don't have to match the English meaning for your language: the important feature is the time span. The spans are approximate; in reality they may vary with the time of year (they might be dependent on sunrise), or context (someone might say they went to bed at 2 at night, and later one say that they woke up at 2 in the morning).
For a list of the day period IDs defined in CLDR for your language, see Day Periods. If you think the rules are wrong (or missing) for your language, please file a ticket and supply the missing information. Here are examples for English and Chinese.
The narrow date fields are the shortest possible names (in terms of width in common fonts), and are not guaranteed to be unique. Think of what you might find on a credit-card-sized wallet or checkbook calendar, such as in English for days of the week:
S M T W T F S
Cyclic Name Sets
Cyclic name sets are used in calendars where naming cycles are used for naming years, months, days, times of day or zodiacs. For example, the Chinese and Hindu calendars each use a 60-name cycle for naming years. Each cyclic name set has standalone and formatting names of varying lengths, similar to months or days.
For lunar calendars that can have months added or removed from the usual set of months in a year, month patterns are used to rename the affected months or the months around them.
Some dates can be specified by giving relative names, such as "this month", "last month" or "next month".
For example, if today is Jan 10, then:
When this month is used, it would be referring to January.
When last month is used, it would be referring to December.
When next month is used, it would be referring to February.
When listing calendar events, or when emails arrived, an interface may abbreviate dates using relative names.
For example, in the following table of sample emails, the emails up to 2 months ago are listed with explicit dates, while the closer ones use relative dates.
Relative date usage examples:
These relative names can be programmatically capitalized (using the contextTransform data) for different contexts, such as for listing in a menu of column of an interface.
💡 Translation Tips
There is a difference between unit patterns (see Plurals) such as "1 year ago" and relative names such as "Last Year".
Consider:
The phrase "1 year ago" has more of sense of a duration.
The phrase "last year" is more sense of relativity to current (For example, on January 2nd, 2019, to refer to an event on December 30th, 2018, you would refer to it as "last year", but NOT "1 year ago."
Some languages have a special word for "The day before yesterday", which may also be displayed for translation in the survey tool if relevant even if English is not available. For example, see Korean.
The names might be used in various contexts and the new guidance is that they should be capitalized as appropriate for the middle of a sentenc
The distinction between 'this' and 'next' may not be present in your language, thus they may have the same translation.
There are a number of patterns like “the week of {0}” used for constructions such as “the week of April 11, 2016” or “the week of April 11–15”. The placeholder can be a full or partial date. There are related week-of date pattern that it should be as consistent with as possible, described here.
<dateFormatItem id="MMMMW" count="one">'week' W 'of' MMM</dateFormatItem>