Develop Reference

When formatting date object - does it matter that the T and the 000Z will be removed when storing to db?

Sorry if its a very basic question but I dont understand the following:
When I format the Date object (no matter what library I used), I get a string.
from this: 2022-11-28T16:55:44.000Z (new Date object)
I get this: 2022-11-28 16:55:44 (or other formats obviously depending how I format it)
Even if I turn it back into an object it, the T and 000Z will never be there anymore. Do I just ignore that (seems like it as any library or date methods are ignoring the T and the string ending when formatting) or do I add it 'back' Isnt it a problem if dates stored in my db are different (for later queries etc.)?

The Z indicates UTC (Coordinated Universal Time, also known as Greenwich Meridian Time), dropping that changes the meaning - unless your browser or server lives in the Greenwich time zone and it is winter (no daylight saving time).
You can convert back and forth between a Date object and a UTC string as follows (my browser lives in the Central European time zone):
> utc = '2022-11-28T16:55:44.000Z'
'2022-11-28T16:55:44.000Z'
> d = new Date(utc)
Mon Nov 28 2022 17:55:44 GMT+0100 (Central European Standard Time)
> d.toISOString()
'2022-11-28T16:55:44.000Z'
Alternatively, you can convert back and forth between a Date object and a formatted string in your browser's or server's time zone (the last line shows that my browser's format differs from yours):
> formatted = '2022-11-28 17:55:44'
'2022-11-28 17:55:44'
> d = new Date(formatted)
Mon Nov 28 2022 17:55:44 GMT+0100 (Central European Standard Time)
> d.toLocaleString()
'11/28/2022, 5:55:44 PM'
But you should not store the Date objects in this format in a database, unless you can guarantee that they are always read and written in the same time zone. For example, if you format a Date object with your browser (in CET) and store it, then someone else who reads it and converts it back to a Date object with their browser in the New Zealand time zone will see a wrong value. Also, dates like 9/11/2022 are ambiguous if the formatting rules are not clear (September 11th or November 9th?).
That's why I would prefer UTC strings when storing Date objects and use formatted strings only for outputting them to the user and for parsing user input.

I see it even stronger: You should never store dates as strings, it's a design flaw. Store always proper Date objects. Here on SO you can find hundreds of questions, where people have problems, because they stored date values as (localized) strings. It is not limited to MongoDB, it applies to any database.
Date objects in MongoDB are UTC times - always and only! Usually the client application is responsible to display the date/time in local time zone and local format.
What do you mean by "turn it back", i.e. how do you do it?
You should not rely on new Date(<string>) without time zone. Some browsers/environments may apply UTC time, others may use current local time zone, see Differences in assumed time zone
Have a look at 3rd party date libraries, e.g. moment.js, Luxon, or Day.js. Usually they provide better control how to parse strings and time zones.

Does JavaScript's Date object automatically handle daylight savings?

I am investigating an issue involving the conversion of serialized UTC dates in to JavaScript date objects; I have read a few questions on this topic already but I am still unclear.
Firstly let me say that I am in the UK. If I take for example the UTC epoch 1473805800000, which is Tue, 13 Sep 2016 22:30:00 GMT, then use that value to create a JavaScript date:
var date = new Date(1473805800000);
console.log(date);
The console logs:
Tue Sep 13 2016 23:30:00 GMT+0100 (GMT Summer Time)
I.e. the browser has recognised that an extra hour needs to be added for DST.
My question is, if I were to run this same code again after the 30th October when the clocks have gone back, would I still get the same result of 23:30, or would it be 22:30 as if it were GMT? In other words, has the browser added an hour because the subject date is DST or because we are currently in DST?
I'm prevented from altering my work station's system clock by group policy, otherwise I would skip it forward in time and test this myself.

Javascript Date objects use a time value that is an offset in milliseconds since 1970-01-01T00:00:00Z. It is always UTC.
If the Date constructor is given a single number argument, it is treated as a UTC time value, so represents the same instant in time regardless of system time zone settings.
When you use console.log(date), the built–in toString method is called which generates an implementation dependent string, generally using the current time zone setting of the host system to create a convenient, human readable string.
The current daylight saving rules in the system are used to determine the offset to use for "local" time, so if the date changes from a time when daylight saving applies to one when it doesn't, the time zone offset will be similarly adjusted (note that daylight saving offsets aren't always 1 hour). It does not matter what the current system offset is, the one used is based on the setting for the date and time that the time value represents.
Also, Date objects are very simple, they're just a time value. The time zone offset comes from system settings, it's not a property of the Date itself.
So, given:
My question is, if I were to run this same code again after the 30th
October when the clocks have gone back, would I still get the same
result of 23:30, or would it be 22:30 as if it were GMT?
the answer is "yes", it will still be 23:30 since on 13 September BST applies. It doesn't matter when the code is run, only what the system offset setting is for that date.

In your case, the Date was created using epoch 1473805800000 and converted to your timezone GMT+0100. Epoch is always UTC time, therefore it was read as UTC and converted to your current timezone.
On September 13 2016, GMT+01 had summer time, therefore it was considered in the calculus.
In my case, I get the following, running the same code as yours:
Thu Sep 15 2016 14:13:14 GMT-0300 (E. South America Standard Time)

javascript parse datetime string in NewYork Timezone

I have a datetime string which represents a local New York time.
12/30/2020 12:00 pm
I want to parse it in javascript to get EPOCH.
The parsing has to work for users which may be in different timezones.
What I did now is
moment("07/13/2015 01:45 am -04:00", 'M/D/YYYY h:mm a Z').unix()
but this is not good because I had to hardcode
-04:00
and assume that the date I'm parsing is Eastern Daylight Saving Time.

Use the moment-timezone add-on.
moment.tz("12/30/2020 12:00 pm", "M/D/YYYY h:mm a", "America/New_York").unix()
Also, be aware that there's no guarantee that the rules for any particular time zone will persist into the future. Who knows if by 2020 if the US government won't change the DST rules again like they last did in 2007. Sure, it's not likely to affect a date in December, but in the general case you can't be certain. Especially when you consider that other time zones have changes often - about a dozen or more changes globally every year.
Oh, and one minor petpeeve... You said:
... to get EPOCH.
The word epoch means "the start of something". The Unix Epoch is 1970-01-01T00:00:00Z. It's never anything else. The value you get back from a unix timestamp is based on the epoch - but it is not itself an epoch. "Epoch Time" is a misnomer. (There are other epochs used in computing, but not with relation to Unix Time).

GMT vs UTC dates

I have a calendar built in JavaScript that compares dates with PHP. The JavaScript date object is set using PHP, but, when I compare future dates, they appear to be out of sync.
PHP is set to GMT and JavaScript is set to UTC; how do these standards differ, and could this be causing the problem?

From Coordinated Universal Time on Wikipedia:
Coordinated Universal Time (UTC) is a time standard based on International Atomic Time (TAI) with leap seconds added at irregular intervals to compensate for the Earth's slowing rotation.
From Greenwich Mean Time on Wikipedia:
UTC is an atomic time scale which only approximates GMT with a tolerance of 0.9 second

One is measured from the sun and another from an atomic clock.
For your purposes, they are the same.

For computers, GMT is UTC+0 - so they are the equivalent.

If you strictly go by the definition of what UTC and GMT are, there is no real practical difference as others have pointed out.
However one needs to be careful as there are certain cases where (possibly legacy) terminology is used such as in the Microsoft Timezone index values
The difference is that in that context, what is referred to as the "GMT timezone" (code 55) is, in reality, the "GMT locale" which is the locale used by Dublin, Edinburgh, Lisbon, London (all of which observe daylight savings time) which is differentiated from Greenwich Standard Time (code 5A) which is used by Monrovia and Reykjavik both of which do not observe daylight savings time.
The practical difference is that if a system is set up to use UTC (code 80000050 under the semantics specified above) then it will not automatically switch to daylight savings time while if you set your time zone to GMT (code 55) then there's a good chance it automatically switches to BST during the summer without you noticing.

How do I get timezone codes such as BST / GMT / CET etc?

I want to show the timezone code (such as BST or GMT) based on the user's locale. However, in each browser it is positioned in different places from new Date().toLocaleString() and on some browsers (such as Opera) it is not available at all.
It looks like the solution would be to get a database or structure of timezone codes against timezone offset but there can be multiple matches (e.g. BST == GMT) and I can't even find such a list.
Does this mean it can't be done?

You have to manually define the timezone differences in your code. It is complicated because GMT time is different than UTC (Zulu) time. GMT includes a change for daylight savings time, while UTC has no daylight savings and is otherwise the same timezone representation.
Additional confusion is that not all political zones define their timezones to vary by an example number of hours. India is UTC + 5.5 hours and Afghanistan UTC + 4.5 hours. Notice that is UTC and not GMT as the base as those countries do not observe daylight savings. Some small island nations in the southwest Pacific can vary on the quarter hour.
Then some political timezone definitions have internal differentiation. Arizona is typically considered to be in the US Pacific timezone, GMT - 8 hours, except that it does not observe daylight savings, so half the year it is in US Mountain timezone as Arizona is really UTC - 8.
With all that confusion there are hundreds of definitions for timezones, and some of those change as political boundaries change. I just say screw it and use either the user's clock time or adjust to UTC time by dynamically adjusting a constant in your JavaScript from the server to reflect a known value that represents UTC time when the user requested the page.