Description

Date

JavaScript Date objects represent a single moment in time in a platform-independent format. Date objects encapsulate an integral number that represents milliseconds since the midnight at the beginning of January 1, 1970, UTC (the epoch).

Note: TC39 is working on Temporal, a new Date/Time API. Read more about it on the Igalia blog. It is not yet ready for production use!


Description

The epoch, timestamps, and invalid date

A JavaScript date is fundamentally specified as the time in milliseconds that has elapsed since the epoch, which is defined as the midnight at the beginning of January 1, 1970, UTC (equivalent to the UNIX epoch). This timestamp is timezone-agnostic and uniquely defines an instant in history.

Note: While the time value at the heart of a Date object is UTC, the basic methods to fetch the date and time or its components all work in the local (i.e. host system) time zone and offset.

The maximum timestamp representable by a Date object is slightly smaller than the maximum safe integer (Number.MAX_SAFE_INTEGER, which is 9,007,199,254,740,991). A Date object can represent a maximum of ±8,640,000,000,000,000 milliseconds, or ±100,000,000 (one hundred million) days, relative to the epoch. This the range from April 20, 271821 BC to September 13, 275760 AD. Any attempt to represent a time outside this range results in the Date object holding a timestamp value of NaN, which is an "Invalid Date".

console.log(new Date(8.64e15).toString()); // "Sat Sep 13 275760 00:00:00 GMT+0000 (Coordinated Universal Time)"
console.log(new Date(8.64e15 + 1).toString()); // "Invalid Date"

There are various methods that allow you to interact with the timestamp stored in the date:

  • You can interact with the timestamp value directly using the getTime() and setTime() methods.
  • The valueOf() and [@@toPrimitive]() (when passed "number") methods - which are automatically called in number coercion - return the timestamp, causing Date objects to behave like their timestamps when used in number contexts.
  • All static methods (Date.now(), Date.parse(), and Date.UTC()) return timestamps instead of Date objects.
  • The Date() constructor can be called with a timestamp as the only argument.

Date components and time zones

A date is represented internally as a single number, the timestamp. When interacting with it, the timestamp needs to be interpreted as a structured date-and-time representation. There are always two ways to interpret a timestamp: as a local time or as a Coordinated Universal Time (UTC), the global standard time defined by the World Time Standard. The local timezone is not stored in the date object, but is determined by the host environment (user's device).

Note: UTC should not be confused with the Greenwich Mean Time (GMT), because they are not always equal - this is explained in more detail in the linked Wikipedia page.

For example, the timestamp 0 represents a unique instant in history, but it can be interpreted in two ways:

  • As a UTC time, it is midnight at the beginning of January 1, 1970, UTC,
  • As a local time in New York (UTC-5), it is 19:00:00 on December 31, 1969.

The getTimezoneOffset() method returns the difference between UTC and the local time in minutes. Note that the timezone offset does not only depend on the current timezone, but also on the time represented by the Date object, because of daylight saving time and historical changes. In essence, the timezone offset is the offset from UTC time, at the time represented by the Date object and at the location of the host environment.

There are two groups of Date methods: one group gets and sets various date components by interpreting the timestamp as a local time, while the other uses UTC.

Component Local UTC
Get Set Get Set
Year getFullYear() setFullYear() getUTCFullYear() setUTCFullYear()
Month getMonth() setMonth() getUTCMonth() setUTCMonth()
Date (of month) getDate() setDate() getUTCDate() setUTCDate()
Hours getHours() setHours() getUTCHours() setUTCHours()
Minutes getMinutes() setMinutes() getUTCMinutes() setUTCMinutes()
Seconds getSeconds() setSeconds() getUTCSeconds() setUTCSeconds()
Milliseconds getMilliseconds() setMilliseconds() getUTCMilliseconds() setUTCMilliseconds()
Day (of week) getDay() N/A getUTCDay() N/A

The Date() constructor can be called with two or more arguments, in which case they are interpreted as the year, month, day, hour, minute, second, and millisecond, respectively, in local time. Date.UTC() works similarly, but it interprets the components as UTC time and also accepts a single argument representing the year.

Note: Some methods, including the Date() constructor, Date.UTC(), and the deprecated getYear()/setYear() methods, interpret a two-digit year as a year in the 1900s. For example, new Date(99, 5, 24) is interpreted as June 24, 1999, not June 24, 99. See Interpretation of two-digit years for more information.

When a segment overflows or underflows its expected range, it usually "carries over to" or "borrows from" the higher segment. For example, if the month is set to 12 (months are zero-based, so December is 11), it become the January of the next year. If the day of month is set to 0, it becomes the last day of the previous month. This also applies to dates specified with the date time string format.


Date time string format

There are many ways to format a date as a string. The JavaScript specification only specifies one format to be universally supported: the date time string format, a simplification of the ISO 8601 calendar date extended format. The format is as follows: 

YYYY-MM-DDTHH:mm:ss.sssZ
  • YYYY is the year, with four digits (0000 to 9999), or as an expanded year of + or - followed by six digits. The sign is required for expanded years. -000000 is explicitly disallowed as a valid year.
  • MM is the month, with two digits (01 to 12). Defaults to 01.
  • DD is the day of the month, with two digits (01 to 31). Defaults to 01.
  • T is a literal character, which indicates the beginning of the time part of the string. The T is required when specifying the time part.
  • HH is the hour, with two digits (00 to 23). As a special case, 24:00:00 is allowed, and is interpreted as midnight at the beginning of the next day. Defaults to 00.
  • mm is the minute, with two digits (00 to 59). Defaults to 00.
  • ss is the second, with two digits (00 to 59). Defaults to 00.
  • sss is the millisecond, with three digits (000 to 999). Defaults to 000.
  • Z is the timezone offset, which can either be the literal character Z (indicating UTC), or + or - followed by HH:mm, the offset in hours and minutes from UTC.

Various components can be omitted, so the following are all valid:

  • Date-only form: YYYY, YYYY-MM, YYYY-MM-DD
  • Date-time form: one of the above date-only forms, followed by T, followed by HH:mm, HH:mm:ss, or HH:mm:ss.sss. Each combination can be followed by a time zone offset.

For example, "2011-10-10" (date-only form), "2011-10-10T14:48:00" (date-time form), or "2011-10-10T14:48:00.000+09:00" (date-time form with milliseconds and time zone) are all valid date time strings.

When the time zone offset is absent, date-only forms are interpreted as a UTC time and date-time forms are interpreted as local time. This is due to a historical spec error that was not consistent with ISO 8601 but could not be changed due to web compatibility. See Broken Parser – A Web Reality Issue.

Date.parse() and the Date() constructor both accept strings in the date time string format as input. Furthermore, implementations are allowed to support other date formats when the input fails to match this format.

The toISOString() method returns a string representation of the date in the date time string format, with the time zone offset always set to Z (UTC).

Note: You are encouraged to make sure your input conforms to the date time string format above for maximum compatibility, because support for other formats is not guaranteed. However, there are some formats that are supported in all major implementations - like RFC 2822 format - in which case their usage can be acceptable. Always conduct cross-browser tests to ensure your code works in all target browsers. A library can help if many different formats are to be accommodated.

Non-standard strings can be parsed in any way as desired by the implementation, including the time zone - most implementations use the local time zone by default. Implementations are not required to return invalid date for out-of-bounds date components, although they usually do. A string may have in-bounds date components (with the bounds defined above), but does not represent a date in reality (for example, "February 30"). Implementations behave inconsistently in this case. The Date.parse() page offers more examples about these non-standard cases.


Other ways to format a date

  • toISOString() returns a string in the format 1970-01-01T00:00:00.000Z (the date time string format introduced above, which is simplified ISO 8601). toJSON() calls toISOString() and returns the result.
  • toString() returns a string in the format Thu Jan 01 1970 00:00:00 GMT+0000 (Coordinated Universal Time), while toDateString() and toTimeString() return the date and time parts of the string, respectively. [@@toPrimitive]() (when passed "string" or "default") calls toString() and returns the result.
  • toUTCString() returns a string in the format Thu, 01 Jan 1970 00:00:00 GMT (generalized RFC 7231).
  • toLocaleDateString(), toLocaleTimeString(), and toLocaleString() use locale-specific date and time formats, usually provided by the Intl API.

Source: Mozilla, https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date
Creative Commons License This work is licensed under a Creative Commons Attribution-ShareAlike 2.5 License.