Develop Reference

How to convert date time saved in New York timezone to local time zone in javascript?

I am getting date time stored as string in New York timezone (GMT -4) format from third-party website. I want to convert it to local time zone using javascript. Date time is saved in following format
"2019-04-15 19:09:16"
I know i can achieve this through MomentJS but I want to know if there is any simple solution beside loading all library to convert date time to local timezone.
On Chrome expected output could be achieved by appending GMT-4 at the end of date and
new Date("2019-04-15 19:09:16 GMT-4")
But this solution doesn't work on Firefox because of invalid format.

If you actually know that the offset is UTC-4, then you simply need to reformat your string to be compliant with the ECMAScript Date Time String Format, which is a simplification of the ISO 8601 Extended Format.
new Date("2019-04-15T19:09:16-04:00")
However, note that New York is on US Eastern Time, which is actually in daylight saving time for the date and time you provided. In other words, it isn't UTC-4 (EST), but rather UTC-5 (EDT). So for that example, it should be:
new Date("2019-04-15T19:09:16-05:00")
But what if you don't know which offset it is for a given time zone on a particular date and time? After all, time zones, daylight saving time transitions, and associated offset are different all over the world, and have changed throughout history. So one cannot just assume a time zone has a single number that is its offset. (Read more under "Time Zone != Offset" in the timezone tag wiki.)
Presently, JavaScript cannot help you with that on its own. Instead, you'll need to use a library, such as the ones referenced here.
For example, using Luxon, you can do the following:
luxon.DateTime.fromISO("2019-04-15T19:09:16", { zone: "America/New_York" }).toJSDate()
In the future, we hope to solve this in the JavaScript language via Temporal objects - which are still in the ECMAScript proposal stage.

convert local timezone timestamp to UTC timestamp

My server returns date data as local timezone timestamps.
On the client-side, I want to display those dates as local date strings. If I do the following, I got the wrong date ("6/30/2014" instead of "7/01/2014")
var ts = 1404172800;
new Date(1404172800*1000).toLocaleDateString()
>>>"6/30/2014"
To prevent this problem, I suppose I have to convert the local timezone timestramp I receive from the server to UTC timestamp before creating the new Date() object.
Am I right? What is the best way to achieve that that will work in most browsers?
Edit:
I confirm that the real date in local time zone should be 7/01/2014. That's local Eastern time UTC -5(-4). but the new Date() object thinks this is UTC but it's not. I suppose it's because the date is returned as a timestamp without having been converted to UTC.

Isn't that right already? Timestamps are always in UTC.
You're seeing 30th June and not 1st of July because when that event happened, in the local time zone, it was still 30th of June. For example, for me it is showing as 1st of July in IST.
Also, this timestamp represents an event which occurred at 1st July 2014 at 00:00:00 GMT exactly. India is GMT+05:30, as you can see in the screenshot - so if the local timezone, even if it is GMT minus one minute, it would still be 30th of June there.

Date of birth: Same date of birth in every local?

Currently im storing the date of birth of a user in milliseconds (since 01.01.1970). Do i have to ensure that it is the same date of birth in every country or is it common that it can happen that it is the 11th November in country X and the 12th November in country Y?
If instead it is common practice to have the exact same date of birth in each country, how could i ensure that the milliseconds i store always point to the exact same day of month in each country?

Ignore time-of-day
Few people know the time-of-day of their birth. So, no, that level of detail is not commonly tracked. You never see time-of-birth and birth-time-zone on passports and such. They track a date-only value, without time of day and without time zone.
Bartenders, border control agents, etc. use the local current date to calculate age, with no attempt to consider time of day or adjust for time zone. Consider that partial-day difference to be truncated, ignored.
To adjust a moment accurately from one time zone to another, you need a date and a time-of-day. Without a time-of-day you have perhaps 23-25 hours of possible moments when their birth may have occurred.
For example, a birth that occurs a few minutes after midnight in Paris (1 or 2 hours ahead of UTC) on the 24th is still “yesterday” the 23rd in Montréal (4 or 5 hours behind UTC). But if that birth occurs at 06:00 in the 24th, then the date is the same (24th) in both Paris & Montreal, but is “yesterday” (23rd) in Vancouver BC and Seattle where the clocks are 7 or 8 hours behind UTC.
SQL
In SQL use a data type akin to the standard DATE type.
Java
In Java, use the LocalDate type. To represent the recurring month and day of the birthday celebration, use the MonthDay class.
For interacting with a database, drivers that comply with JDBC 4.2 should be able to work directly with LocalDate via the getObject & setObject methods on a PreparedStatement. If not, fall back to using the old java.sql.Date. New methods added to that old class facilitate conversion.
ISO 8601
When generating string representations of date-time values, use the formats defined in the ISO 8601 standard such as YYYY-MM-DD, ex: 1960-07-11. For date without year use --MM-DD, ex: --07-11. The java.time classes in Java use ISO 8601 formats by default when parsing and generating Strings.
Forcing time-of-day
If for some reason you are forced to put a date-only value into a date-time field, then you must set some arbitrary time-of-day. Noon is one possibility. I suggest setting the time portion to the first moment of the day.
First moment of the day
Be aware that the first moment is not always 00:00:00. Daylight Saving Time (DST) and perhaps other anomalies affect midnight in some time zones. So first moment of the day might be 01:00:00 for example. Java can determine the first moment of the day appropriate to a particular time zone.
ZoneId zoneId = ZoneId.of( "America/Montreal" );
LocalDate today = LocalDate.now( zoneId );
ZonedDateTime startOfToday = today.atStartOfDay( zoneId );

It is up to you to decide what time zone to interpret a selected date of birth as and what time zone to use when displaying the date of birth. In my opinion, it is logical to always use the timezone of the place of birth (if you wish to collect that) when converting the date of birth from a timestamp to readable form and when storing it. Otherwise, you can always use GMT or any other timezone as your convention. This will ensure that all users in all countries will see the same date of birth but it is recommended to append the time zone to the date representation to prevent confusion. You may of course choose to interpret dates as GMT based when creating the timestamp to store and then render the date of birth using a user-defined timezone (possibly timezone for the user's account). In this case, the date (and time if you include the time of birth) will appear different for each user.

will conversion of timestamp to date in different timezones returns different date and time?

I am trying to convert my current date into timestamp and send it to API to save it. When I try to retrive the timestamp back from API and convert it to date, it is retriving coorectly.
The issue is when I send current timestamp to API and if a person in singapore fetch the same timestamp from API and try to convert to date, It shows (date and time I have sent to API)+2.30hr.
I use new Date(timestamp) in javascript to convert timestamp into date.
Similarly it differs to different timezone.
How can I solve this issue?

You can use UTC time to standardize between various locations and send it in your api, and when someone wants to work in singapore receive the datetime in UTC and then convert it to his local time-zone.
var utcDate = new Date(Date.UTC(96, 11, 1, 0, 0, 0));
The constructor of Date.UTC
Date.UTC(year, month[, day[, hour[, minute[, second[, millisecond]]]]])

Unix like timestamps in Javascript are the number of milliseconds since Jan 1 1970 with no time zone offset. Date.now() returns such a timestamp.
If you send "your date and time" to the API as a timestamp, retrieve it and convert back into "date and time" in a browser on your PC, the conversion back will be from UTC into local time as defined by the local zone setting of your PC. Somebody 2.5 hours west of you, with a local time 2.5 hours later, will convert the same UTC timestamp into a local time value 2.5 hours later than yours.
How to resolve the issue depends on what needs to be achieved. Should global users see timestamps in your timezone, UTC, their timezone, a timezone specified on the website, or relative to a given location, such as the departure and arrival airports of aircraft flights? This needs to be decided first, before looking into Date object methods with "UTC" in their names :-).
In response to comment of using OP's timezone:
If your location does not use daylight saving, you could include your fixed timezone offset in page script and use it in conjunction with users' timezone to produce a date and time string matching your local time of creation. A problem if daylight saving is introduced to your area in the future.
For daylight saving, you could add your easterly time zone offset in milliseconds to a Date.now() time stamp, store the result in the API, retrieve the timestamp and convert into a date and time string using the .getUTCxxx methods inherited from Date.prototype. Such a conversion should match your local time when the timestamp was created. The method may have valid criticisms but at least should meet with requirements!
Ideally the UTC timestamp would be stored unchanged, and the local timezone offset of the creator stored as well.

ExtJS dates and timezones

I have a problem with the Ext Date class seemingly returning the wrong timezone for a parsed date. Using the code below I create a date object for the 24th May, 1966 15:46 BST:
date = "1966-05-24T15:46:01+0100";
var pDate = Date.parseDate(date, "Y-m-d\\TH:i:sO", false);
I then call this:
console.log(pDate.getGMTOffset());
I am expecting to get the offset associated with the orignal date back (which is GMT + 1), but instead I get the local timezone of the browser instead. If the browser is set to a timezone far enough ahead GMT, the day portion of the date will also be rolled over (so the date will now appear as 25th May, 1966).
Does anyone know how to get around this and get Ext to recognise the correct timezone of the parsed date rather than the local browser timezone?
If this is not possible, can Ext be forced to use GMT rather than trying to interpret timezones?

I checked the parseDate() implementation in ExtJS source code and the documentation of Date in core JavaScript, the Date() constructor used by ExtJS does not support time zone information. JavaScript Date objects represent a UTC value, without the time zone. During parsing in ExtJS source code, the time zone is lost while the corresponding offset in minutes/seconds is added to the Date.
I then checked the source code of getGMTOffset() defined by ExtJS: it builds a time-zone string using the getTimezoneOffset() function defined in JavaScript.
Quoting the documentation of getTimezoneOffset():
The time-zone offset is the difference
between local time and Greenwich Mean
Time (GMT). Daylight savings time
prevents this value from being a
constant.
The time-zone is not a variable stored in the Date, it is a value that varies according to the period of the year that the Date falls in.
On my computer, with a French locale,
new Date(2010,1,20).getTimezoneOffset()
// -60
new Date(2010,9,20).getTimezoneOffset()
// -120
Edit: this behavior is not specific to Date parsing in ExtJS, the following note in the documentation of Date.parse() on Mozilla Doc Center is relevant here as well:
Note that while time zone specifiers
are used during date string parsing to
properly interpret the argument, they
do not affect the value returned,
which is always the number of
milliseconds between January 1, 1970
00:00:00 UTC and the point in time
represented by the argument.

I'm a little late but in latest ExtJS, you can pass an optional boolean to prevent the "rollover" in JS
http://docs.sencha.com/ext-js/4-0/#!/api/Ext.Date-method-parse

My two cents, because I can't really set all my time to 12:00 like Tim did. I posted on the sencha forum