We Keep Coding

Using moment.js timezone to get day extremes in another timezone (but the answer in UTC)

I want to work out the day extremes (midnight to midnight) for a particular day, where that day is a whole number of days relative to now (i.e. relative to Date.now())... but for a different timezone to UTC. But I want the answer (midnight times) back in UTC time (in milliseconds, similar to what you get with Date.now()), so that I can feed those to an API that expects UTC times, to get the exact right time range of data. I have tried to use moment.js timezone but am getting horribly stuck... I found this answer but it doesn't work in a different timezone.

I suggest you consider using Luxon, which is essentially the replacement for moment.js.
The algorithm is create a date for now in the required representative location, subtract the required number of days, then set to the start of day, then get the time value, e.g.
let DateTime = luxon.DateTime;
// Create date for 00:00:00 3 days ago in Denver
let d = DateTime.local() // Create a date
.setZone('America/Denver') // Set to Denver
.minus({days:3}) // Subtract 3 days
.startOf('day'); // Set to start of day
// Create date for end of day
let e = d.endOf('day');
// Denver 3 days ago at start and end of day
console.log('Start of day: ' + d.toISO() + '\nTime value : ' + d.ts);
console.log('End of day: ' + e.toISO() + '\ntime value : ' + e.ts);
<script src="https://cdn.jsdelivr.net/npm/luxon#1.24.1/build/global/luxon.min.js"></script>
Note that 3 days ago in Denver might be a different date to 3 days ago in the host system because of the offset differences. E.g in Sydney, Australia at 9 am on 20 July it's 5 pm on 19 July in Denver, so subtracting 3 days in Sydney is 17 July but 16 July in Denver.

Moment will allow you to do this fairly easily:
function getUTCMidnightMillis(timezone, days_ago) {
return moment() // Current time.
.tz(timezone) // Convert to desired timezone.
.subtract(days_ago, 'days') // Go back x days.
.startOf('day') // Get start of day, aka Midnight!
.utc() // Convert value into UTC.
.valueOf() // Return milliseconds since unix epoch.
}
console.log("Midnight in Denver:", getUTCMidnightMillis("America/Denver", 0))
console.log("Midnight in New York:", getUTCMidnightMillis("America/New_York", 0))
Which produces the output:
Midnight in Denver: 1594274400000
Midnight in New York: 1594267200000
And indeed, you can verify that is correct:
new Date(1594274400000).toISOString()
// Produces: "2020-07-09T06:00:00.000Z"
For the 9th of July, 2020, we observe daylight savings in Denver, making our UTC offset -6 hours. So the above timestamp (6:00am UTC) is the same moment at which it is midnight in Denver.

How to convert a JS Date (programmatically) into a Google Sheet Serial Number and vice-versa?

So, I have a JS date
> new Date()
Mon Aug 05 2019 06:55:46 GMT-0700 (Pacific Daylight Time
In Google Sheets API, the default dateTime render option is DateTimeRenderOption.SERIAL_NUMBER, which as per the documentation says
Instructs date, time, datetime, and duration fields to be output as doubles in "serial number" format, as popularized by Lotus 1-2-3. The whole number portion of the value (left of the decimal) counts the days since December 30th 1899. The fractional portion (right of the decimal) counts the time as a fraction of the day. For example, January 1st 1900 at noon would be 2.5, 2 because it's 2 days after December 30st 1899, and .5 because noon is half a day. February 1st 1900 at 3pm would be 33.625. This correctly treats the year 1900 as not a leap year.
I want to know how to convert the JS Date to SERIAL_NUMBER using API/library and back from SERIAL_NUMBER to JS Date object?

This will get you the serial number. You may or may not want to trim it
function createSerialNum() {
var oneDay = 24 * 60 * 60 * 1000;
var firstDate = new Date(1899, 11, 30);
var secondDate = new Date();
console.log(secondDate);
var secondDateMidnight = new Date(secondDate.getFullYear(), secondDate.getMonth(), secondDate.getDate());
var diff = secondDate.getTime() - secondDateMidnight.getTime();
var left = Math.round(Math.abs((firstDate.getTime() - secondDate.getTime()) / (oneDay))) - 1;
var right = diff / oneDay;
var result = left + right;
console.log(result);
return result;
}
This will turn back it into a date
function createDateFromSerial(serialNum){
serialNum = String(serialNum).split(".");
var ogDate;
var oneDay = 24 * 60 * 60 * 1000;
var firstDate = new Date(1899, 11, 30);
var days = serialNum[0];
var ms = serialNum[1] * oneDay;
ms = String(ms).substring(0, 8);
firstDate.setDate(days);
ogDate = new Date(firstDate.getFullYear(), firstDate.getMonth(), firstDate.getDate(), 0, 0, 0, ms);
console.log(ogDate);
return ogDate;
}

Before we get to conversions first some notes on the serial number format.
Serial Format
As described in the documentation, the serial number has two parts. The integer before the decimal representing the days from December 30th 1899, and the fraction representing the time of day, without a timezone. That is, 0.5 always represents the time 12:00 (Noon), regardless of the user machine or sheet's set timezone, daylight savings, or anything else.
Time zone:
The Serial number is without time zone. This means that a cell value of 0 will always be rendered as "12/30/1899 0:00:00", regardless of the sheet's timezone.
The sheet's timezone only affects functions such as NOW() or TODAY(), and changing the timezone will change their numeric output (and not change the numeric output of TIME() functions).
For example:
Set a cell to the formula =NOW(), then format the cell to render as a number.
Change the sheet's timezone to a different timezone +6 hours from what it previously was.
Make a change to the sheet so the NOW() value recalculates.
Notice that the numeric value will change by about +0.25 to represent 6 hours difference.
Also note that no other date-time cells change their display from the time zone change.
When getting data via spreadsheets.values.get, the default valueRenderOption is
ValueRenderOption.FORMATTED_VALUE, which means that the default dateTimeRenderOption of DateTimeRenderOption.SERIAL_NUMBER is ignored.
Formatting
A DATE_TIME formatted cell will be in a locale format according to the spreadsheet's locale, not the user machine's locale, e.g. "9/12/2020 8:15:40" or "12.9.2020 8:15:40" if the spreadsheet is set to German. If all you're doing with the date is displaying it, and you don't care that there may be a locale mismatch, this is ok. Note that it's not ok to use Date.parse() on this string, as the value will be inconsistent if the spreadsheet locale is something other than English.
If you change valueRenderOption to ValueRenderOption.UNFORMATTED_VALUE, we get the SERIAL_NUMBER value of dates, which I'll give formulas to below.
Writing
To write to the sheet using a JS Date, we don't necessarily need to convert it to lotus serial format. We can write to the cell using a formula:
`=DATE(${date.getFullYear()}, ${date.getMonth() + 1}, ${date.getDate()}) + TIME(${date.getHours()}, ${date.getMinutes()}, ${date.getSeconds()})`
This will have a formula output of something like: =DATE(2020, 9, 12) + TIME(9, 15, 41)
That cell will render as 9/12/2020 9:15:41, regardless of timezone.
In that example the cell was written with the date object's local time. We can write it as the date object's UTC time via:
`=DATE(${date.getUTCFullYear()}, ${date.getUTCMonth() + 1}, ${date.getUTCDate()}) + TIME(${date.getUTCHours()}, ${date.getUTCMinutes()}, ${date.getUTCSeconds()})`
Which you use depends on your use case. Using the local time means that if the local time is 3:15, the cell renders within sheets how you'd expect as "3:15".
Using UTC time means that if the local time is 3:15, and your timezone is -600GMT, the cell will display as "9:15", possibly adding confusion.
Using local time can be a problem however if you are finding the difference between two dates. Take the case of daylight savings. If for example you are in America/Chicago timezone with daylight savings time ending 2am Nov 1, 2020, then the local time difference between 2am and 1am is 2 hours.
(new Date(2020, 10, 1, 2)) - (new Date(2020, 10, 1, 1)) // 7200000 (2 hours) (note JS month is 0-indexed)
But in Sheets, there is no daylight savings time, so subtracting those two dates will be 1 hour, regardless of the spreadsheet's set timezone.
So we have a few options:
Consider the sheet date_time values as UTC times.
Pros: Times are unambiguous. Apps can render the time stamp in the user's timezone and save as UTC.
Cons: Editing the sheet directly can be confusing, as you'd need to convert local times to UTC by hand. Would not work with NOW() / TODAY() functions.
Consider the sheet values to have no time zone.
Pros: Times work with NOW() and TODAY() methods. When editing the sheet directly, times are always entered as the user's local time.
Cons: Timezone information is lost. When calculating the difference between times, daylight savings time changes can cause calculation to be off by an hour.
Consider the sheet values to be relative to the time zone in which the sheet is set.
Pros: Times are unambiguous. Times work with NOW() and TODAY() methods.
Cons: Sheet time zones are always standard time, so editing the sheet directly has the same problems as #1. Converting between sheet's standard time and user's local time is difficult and requires external libraries.
No matter which method we choose, we'll start with the same formulae.
Finally, the Code
(Note that this is very similar to Jeremy Ring's answer, except this will handle DST changes)
/**
* Converts a Lotus serial format to a JS UTC date.
* #param serial {number}
* #return {Date}
*/
function serialToDateUTC(serial) {
const intPart = Math.floor(serial);
const fracPart = serial - intPart;
const time = Math.round(fracPart * DAY_TO_MS);
const date = new Date(Date.UTC(1899, 11, 30 + intPart) + time);
return date;
}
/**
* Converts a JS Date to Lotus serial format.
* #param date {Date}
* #return {number}
*/
function utcDateToSerial(date) {
const dateSansTime = new Date(Date.UTC(date.getUTCFullYear(), date.getUTCMonth(), date.getUTCDate()));
const intPart = Math.round((dateSansTime.getTime() - Date.UTC(1899, 11, 30)) / DAY_TO_MS);
const fracPart = (date.getTime() - dateSansTime.getTime()) / DAY_TO_MS;
return intPart + fracPart;
}
To display the UTC date, use Date.toUTCString (Or Intl.DateTimeFormat with the timeZone set). Example:
console.log(serialToDateUTC(44086.344212963).toUTCString()); // 9/12/2020 8:15:40
(Option 1)
If we wish to store in sheets as UTC, and display to the user in local time, we read/write to sheets with these UTC conversions, but then display locally via Date.toLocaleString or Intl.DateTimeFormat
Note that this option it may be confusing when editing the time directly within the Google document; the times will need to be entered in the UTC timezone.
(Option 2)
If we're ignoring time zone, this means we're considering the date/time value from sheets to always be local to the user, regardless of their timezone.
For this, if we have a Date with local time 4:24, we want to store 4:24 in sheets (using a formula this is simply =TIME(4, 24, 0).
To do this, we can use the same methods posted earlier, but coerce/pretend that the local time is a UTC time. E.g.
const timestamp = new Date(); new Date(Date.UTC(timestamp.getFullHours(), timestamp.getMonth(), timestamp.getDate(), timestamp.getHours(), timestamp.getMinutes(), timestamp.getSeconds()));
This will make time differences unstable -- Consider a timesheet application where you took a start time and an end time via Date.now() or new Date(), and had a duration cell with the formula end time minus start time. Coercing this to standard time may then lose or gain an hour in the difference if we straddle the time change.
(Option 3)
Treating all times local to the Sheet's timezone.
This requires us to get two pieces of information. The cell data, and the sheet's timezone. JavaScript natively has no way to create a Date in another timezone, nor does it have a way to get a timezone offset from an arbitrary timezone. To do this we'll need an external library such as countries-and-timezones.
Get the timezone with the Google files.get api, then get the dstOffset (not the utc offset) from the countries-and-timezones lookup. Use that offset to adjust the sheet's timezone from the local timezone's Date.getTimezoneOffset(). Yep, kinda gnarly.

I've been using this for Google Sheet API. Works fine for me.
// Hour format: HH:MM
// Date format: YYYY-MM-DD
function serialDate(hour, date) {
let leftDate = date;
leftDate = new Date(leftDate);
leftDate = leftDate.getTime();
let serialNumberReference = (new Date('1899-12-30')).getTime();
leftDate = (leftDate - serialNumberReference) / (3600 * 24 * 1000);
let rightDate = date;
rightDate = (new Date(rightDate + ' ' + hour)).getTime() - (new Date(rightDate + ' 00:00').getTime());
rightDate = rightDate / (3600 * 24 * 1000);
return leftDate + rightDate;
}

(The algorithm for this is very similar to the one for converting between Celsius and Fahrenheit, which you may be vaguely familiar with.)
There are three main differences between the scale used for JavaScript dates and the one you describe for Google Sheets:
1) JS dates are millisecond-based, whereas Google Sheets dates are day-based,
2) JS dates take 1-Jan-1970 (at 12:00:00 AM UTC) to equal zero, while Google Sheets dates use 30-Dec-1900 for this purpose, and
3) The Date (and Time) constructor in Google Sheets expects its input's timezone to match UTC, whereas JavaScript's Date constructor uses the timezone of whatever location the script runs in.
To convert between the two formats -- as well adjusting for timezone handling -- we need to "stretch" the scale (using multiplication/division) to get from days to milliseconds, and we also need to "shift" the scale (using addition / subtraction) to account for the different interpretations of 'zero'.
This shows in detail how it can be done:
(Note that this script has not been tested using Google Sheets, with the exception of the one example value shown here.)
// Defines constants in milliseconds (JavaScript's unit for dates)
const MS_PER_MINUTE = 60000; // Assumes no leap year adjustment in this minute
const MS_PER_DAY = 86400000; // Assumes no leap year adjustment in this day
const MS_PER_70YEARS_2DAYS = 2209161599801; // Diff between gSheets' & unix's "zero"
// Defines functions to build JS UTC Date objects
/* (The first function makes a preliminary Date object, calculates the difference
between the user's timezone and UTC, and use this to make the final Date object) */
function newUTCDateFromComponents(YYYY, MM, DD = 1, hh = 0, mm = 0, ss = 0){
// Takes 2 to 6 arguments (the components of a Date), returns a UTC Date object
const date = new Date(YYYY, MM, DD, hh, mm, ss);
const offsetMillisecs = date.getTimezoneOffset() * MS_PER_MINUTE;
return new Date(date.getTime() - offsetMillisecs);
}
function newUTCDateFromTimestamp(timestamp){
// Takes a timestamp, returns a UTC Date object
const date = new Date(timestamp);
return date;
}
// Defines functions to convert between JavaScript timestamps and gSheets dates
function gsheetsDateToJsTimestamp(days){
const jsTimestamp = (days * MS_PER_DAY) - MS_PER_70YEARS_2DAYS;
return jsTimestamp;
}
function jsUTCTimestampToGsheetsDate(millisecs){
let days = (millisecs + MS_PER_70YEARS_2DAYS) / MS_PER_DAY;
days = Math.ceil(days * 100000) / 100000; // Rounds the result up to 5 digits
return days;
}
//
// Examples
//
// JS to gSheets
const jsUTCDateSource = newUTCDateFromComponents(2019, 0, 1, 16, 20); // 2019-JAN-01, 4:20PM
const jsUTCDateStringSource = jsUTCDateSource.toUTCString();
const jsUTCMillisecSource = jsUTCDateSource.getTime();
const gsheetsDateResult = jsUTCTimestampToGsheetsDate(jsUTCMillisecSource);
console.log(`${jsUTCDateStringSource}
from JS (milliseconds since Jan 1, 1970 began): ${jsUTCMillisecSource}
to Google Sheets (days since Dec 30, 1899 began): ${gsheetsDateResult}`);
console.log(`-----------`);
// gSheets to JS
const gsheetsDateSource = 43466.68056; // 2019-JAN-01, 4:20PM
const jsMillisecsResult = gsheetsDateToJsTimestamp(gsheetsDateSource);
const jsUTCDateResult = newUTCDateFromTimestamp(jsMillisecsResult);
const jsUTCMillisecsResult = jsUTCDateResult.getTime();
const jsUTCDateStringResult = jsUTCDateResult.toUTCString();
console.log(`from Google Sheets: ${gsheetsDateSource}
to JS: ${jsUTCMillisecsResult} // off by a fraction of a second (see below)
human-readable string: ${jsUTCDateStringResult}`);
console.log(`NOTE: The result is off by a fraction of a second due to rounding
but evaluates to the same human-readable string.`);

Date to Serial Number: (date.getTime() - new Date(1899, 11, 30).getTime()) / (24 * 60 * 60 * 1000)
Serial Number to Date: new Date(serialNumber * 24 * 60 * 60 * 1000 + new Date(1899, 11, 30).getTime())

JavaScript Date to Delphi TDateTime

I need to send via AJAX a date for a delphi server that accept the date in float format and set a TDateTime property.
Eg.
var
date: TDateTime;
begin
date := StrToFloat(Request.QueryFields.Values['date']);
end;
Delphi TDateTime start from 30/12/1989, i have tested with:
var
date: TDateTime;
begin
date := StrToFloat('0');
ShowMessage( DateTimeToStr(date) ); // show: 30/12/1899
end;
JavaScript Date start from unix epoch, i have tested with:
console.log(new Date(0)); // Thu Jan 01 1970 01:00:00 GMT+0100
a simple conversion seem subtract the difference, but doesn't works, eg.:
// javascipt
var delphiTime = (new Date("07-24-2019") - new Date("12-30-1899")) / 1000;
console.log(delphiTime ); // 3773084400
// delphi
ShowMessage( DateTimeToStr(3773084400) ); // show 00/00/00
the strange fact, on delphi, Now is 43670.654378:
ShowMessage( FloatToStr(Now) ); // 43670.654378
In delphi 0 is 1899 and 43670 is 2019...
How works the date format in Delphi and how convert a unix date to delphi date with math?
Side note: i can't modify the server, i need to solve the issue client side with javascript
UPDATE:
In Delphi the float value = 1 would be 31.12.1899, 2 = 01.01.1900 and so on. Each unit seem a day.
function jsDateToDelphiDate(date){
const seconds = (new Date(date).getTime() - new Date("12-30-1899").getTime()) / 1000;
const days = seconds / 60 / 60 / 24;
return days;
}
console.log(jsDateToDelphiDate(new Date("07-24-2019 16:00:00"))); // 43670.625
43670.625 on delphi is 23/07/2019 15:00.
Why i lose 1 hour?

How works the date format in Delphi
This is fully documented on Embarcadero's DocWiki:
System.TDateTime
The TDateTime class inherits a val data member--declared as a double--that holds the date-time value. The integral part of a TDateTime value is the number of days that have passed since December 30, 1899. The fractional part of a TDateTime value is the time of day.
...
The following table displays examples of TDateTime values and their corresponding dates and times:
Value Description
0 December 30, 1899; 12:00 A.M.
2.75 January 1, 1900; 6:00 P.M.
-1.25 December 29, 1899; 6:00 A.M.
35065 January 1, 1996; 12:00 A.M.
how convert a unix date to delphi date with math?
Side note: i can't modify the server, i need to solve the issue client side with javascript
A Unix date/time is represented as the number of seconds since January 1 1970 00:00:00 UTC. Delphi has a UnixDateDelta constant in the SysUtils unit which is defined as 25569, the number of days from December 31 1899 to January 1 1970. So, a TDateTime value of 25569.0 exactly represents January 1 1970 00:00:00 (UTC vs local is up to you to decide when creating a TDateTime). You can then add seconds to that value to get the final TDateTime value for any Unix date/time.
In a TDateTime, you can add whole days to the integral portion (ie, Unix + 1 day = 25569.0 + 1 = 25570.0), but adding seconds within a day is slightly more work, as seconds are not represented as-is in TDateTime, as you can see in the table above. 0.25 is 6:00 AM (21600 seconds after midnight) and 0.75 is 6:00 PM (64800 seconds after midnight). So seconds are represented in TDateTime as a fraction with 86400 (the number of seconds in a day) as the denominator.
A JavaScript Date object is represented as the number of milliseconds since midnight on January 1 1970. You can divide a Date value by 1000 to get whole seconds, and divide that value by 86400 to get whole days and fractional seconds, which you can then add to 25569.0 to produce a TDateTime value.
function jsDateToDelphiDate(dateToConvert){
const UnixDateDelta = 25569.0;
const SecsPerDay = 86400;
const MSecsPerSec = 1000;
var UnixSeconds = dateToConvert.getTime() / MSecsPerSec; // 1563984000
var SecsToAdd = UnixSeconds / SecsPerDay; // 18101.666666666668
return UnixDateDelta + SecsToAdd;
}
// don't forget to force UTC, or else the Date value
// will be skewed by the local timezone offset...
console.log(jsDateToDelphiDate(new Date("2019-07-24T16:00:00Z"))); // 43670.66666666667
console.log(jsDateToDelphiDate(new Date(Date.UTC(2019, 6, 24, 16, 0, 0)))); // 43670.66666666667
Delphi has a UnixToDateTime() function in the DateUtils unit which performs this calculation for you. So, if you can change your AJAX code to pass a Unix timestamp as-is to Delphi, you can let Delphi calculate a suitable TDateTime.
Note, in this example, the resulting TDateTime value is in UTC. After transmitting the value via AJAX to Delphi, if your Delphi code needs a TDateTime in local time, that is a simple calculation to adjust the TDateTime based on the local machine's timezone offset in minutes, which you can get using platform APIs, such as GetTimeZoneInformation() on Windows, etc. Delphi has an IncMinute() function in the DateUtils unit that you can use for that adjustment.

In JS, valueOf Date is in milliseconds. If you want to convert it to days, simply divide it by 24*60*60*1000.

To convert the return value of new Date().valueOf() to Delphi TDateTime you can use this function:
function jsDateToDelphiDate(millis: int64): TDateTime;
begin
var UnixSeconds: Integer := Round(millis / MSecsPerSec);
Result := UnixToDateTime(UnixSeconds, False);
end;

Date appears to be changing time zone from daylight to standard upon calculation

I have a jQuery range slider that is supposed to increase and decrease the date range by a week with each value. When incrementing past a certain point (November 1st in my example) the time zone changes from daylight to standard. I assume it has something to do with the way I'm calculating the new date but I can't seem to figure out what it is.
I calculate it with:
new Date(minDate.getTime() + (sliderValue * 7) * 1000 * 60 * 60 * 24)
Here's an example fiddle: https://jsfiddle.net/aedryan/f4pvg84e/

Your code is actually working fine. The reason it changes after November 1 is because we switch from Eastern Daylight Time (EDT) to Eastern Standard Time on that date - in both cases you are representing the eastern time zone. Btw, for the future this is a nice way of adding days to a date:
/**
* extends the functionality of the Date() object to include a function called addDays that adds days to
* a javascript date based on an integer
* #param days
* #returns {Date}
*/
Date.prototype.addDays = function(days){
var dat = new Date(this.valueOf());
dat.setDate(dat.getDate() + days);
return dat;
};

You were calculating days by millisecond. However, November 1st was in fact day light savings (welcome to the wonderful world of time culture). As a result your times are off by 1 hour and that means you count 23 hours for one day and only get +6.
As opposed to making these changes by millisecond, simply add the days. This can be done easily in JavaScript as when the days extend past the amount available that month it just returns the adjusted date. That means you can use this for your newDate forumla
var newDate = new Date(2015, 7, 23+(ui.value*7));
Which looks like this: https://jsfiddle.net/u2h261ka/

Date subtraction in JavaScript

I have two text boxes which accept Start Date and End Date respectively, in format YYYY/MM/DD.
I need to alert the user if he selects an end date that exceeds the start date by 50 days.
Here's what I have so far:
var startDate = new Date(document.getElementsByName('MYSTARTDATE').value);
var endDate = new Date(document.getElementsByName('MYENDDATE').value);
if ((endDate - startDate) > 50)
{
alert('End date exceeds specification');
return false;
}
Just as an example, when I select Start Date as 2012/01/22 and End Date as 2012/02/29
startDate = 'Sun Jan 22 00:00:00 UTC +0530 2012'
endDate = 'Wed Feb 29 00:00:00 UTC +0530 2012'
And the result for endDate - startDate is 3283200000, instead of 38.What am I doing wrong?

3283200000 is 38 days in milliseconds.
38 days x 24 hours x 60 minutes x 60 seconds x 1000 milliseconds
Also, there are 38 days between those two dates, not 39.
An easy solution is to have a variable (constant really) defined as the number of milliseconds in a day:
var days = 24*60*60*1000;
And use that variable as a "unit" in your comparison:
if ((endDate - startDate) > 50*days) {
...
}

The solution by Jeff B is incorrect, because of daylight savings time. If the the startDate is, say, on October 31, and the endDate is on December 20, the amount of time that has actually elapsed between those two times is 50 days plus 1 hour, not 50 days. This is especially bad if your program doesn't care about the time of day and sets all times at midnight - in that case, all calculations would be off by one for the entire winter.
Part of the correct way to subtract dates is to instantiate a new Date object for each of the times, and then use an Array with the number of days in each month to compute how many days have actually passed.
But to make things worse, the dates that Europe changes the clocks are different than the dates that the clocks are changed in New York. Therefore, timezone alone is not sufficient to determine how many days have elapsed; location is also necessary.
Daylight savings time adds significant complexity to date handling. In my website, the function needed to accurately compute the number of days passed is nearly a hundred lines. The actual complexity is dependent on whether the calculations are client side or server side or both and who is viewing the data.