DayPilot uses a special class for representing a DateTime value on the client side.
The DayPilot.Date class reuses instances for the same points in time.
Same strings
> new DayPilot.Date("2023-01-01T00:00:00") === new DayPilot.Date("2023-01-01T00:00:00"); true
Different strings representing the same date/time
> new DayPilot.Date("2023-01-01T00:00:00") === new DayPilot.Date("2023-01-01"); true
DayPilot.Date allows direct comparison using >, <, ==, === operators:
> new DayPilot.Date("2023-02-01") > new DayPilot.Date("2023-01-01"); true
The values are normalized:
> new DayPilot.Date("2023-01-01") === new DayPilot.Date("2023-01-01T00:00:00"); true
The DayPilot.Date instances are immutable. The internal .ticks and .value properties are read-only.
Calling toString() without parameters will return the ISO 8601 representation of the input value, e.g. "2023-05-27T13:15:00".
No time zone identifier is used. See also the "Time Zones" section below.
You can use toString(format) to get a locally formatted string.
See toString(format) for the list of supported format strings.
Example - sending the value to the server
> var date = new DayPilot.Date("2023-05-27T13:15:00"); > date.toString() "2015-05-27T13:15:00"
Example - presenting the value to the user
> var date = new DayPilot.Date("2023-05-27T13:15:00"); > date.toString("M/d/yyyy HH:mm") "5/27/2023 13:15"
Example - get a Date object that returns a correct string using .toString()
> var date = new DayPilot.Date("2023-05-27T13:15:00"); > date.toDateLocal().toString(); 'Sat May 27 2023 13:15:00 GMT+0200 (Central European Summer Time)'
The controls (to be able to perform correct calculations) work with an idealized continuous timezone.
By calling toDateLocal() you say - I pretend the idealized timezone is my local timezone.
Use DayPilot.Date.parse(string, pattern, locale) to read the value from a custom-formatted string.
The following methods are available:
The original DayPilot.Date object is not modified (instances are immutable).