Most implementations will support IANA time zone identifiers, such as 'America/New_York'. This is accomplished via the timeZone option to toLocaleString and its variations. In environments that have implemented the ECMASCript Internationalization API (aka "Intl"), a Date object can produce a locale-specific string adjusted to a given time zone identifier. The original local time and offset are not retained in the resulting Date object. It uses this to adjust the value being parsed, and stores the UTC equivalent. It can parse a string containing a numeric UTC offset from any time zone. The only operations the Date object can do with non-local time zones are: The details vary per function, and some are implementation-specific.
#GMT NEW YORK TIME ZONE HOW TO#
If the function produces a string, then the computer's locale information may be taken into consideration to determine how to produce that string. When various functions of the Date object are used, the computer's local time zone is applied to the internal representation. There is no time zone or string format stored in the Date object itself. The internal representation of a Date object is a single number, representing the number of milliseconds that have elapsed since 00:00:00 UTC, without regard to leap seconds. It has very few facilities for working with time in other time zones. JavaScript's Date object tracks time in UTC internally, but typically accepts input and produces output in the local time of the computer it's running on.
0 kommentar(er)
