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.

Differences in dates between .Net and Javascript

I had an issue where dates were out by one day when displaying on an asp.net web form. These dates are only used for display so I can pass them as strings to resolved the issue, but I'm curious about why I'm seeing this behaviour.
I'm in Ireland, and while Ireland is more or less in line with GMT, we use IST (Irish Standard Time) during summer instead of DST and then revert to GMT for Winter. This has the same effect as being on GMT, but "officially" is slightly different.
As we're not on GMT, in the past, IST and DST didn't always line up.
For example, in 1958, IST started in the 20th April and ended on the 5th October whereas, DST started on the 27th of April and ended on 26th of October.
So if a date between the 5th and 26th of October 1958 is passed to JS, JS will display it as the previous day.
I wrote this this code to try and understand what's going on:
DateTime date = new DateTime(1958, 10, 4);
while (date <= new DateTime(1958, 10, 30))
{
Console.WriteLine($"normal : {date} | isDst? : {date.IsDaylightSavingTime()}");
Console.WriteLine($"universal: {date.ToUniversalTime()} | isDst? : {date.ToUniversalTime().IsDaylightSavingTime()}");
Console.WriteLine($"local : {date.ToLocalTime()} | isDst? : {date.ToLocalTime().IsDaylightSavingTime()}");
Console.WriteLine("-------------------------");
date = date.AddDays(1);
}
Which produced this output (truncated):
So I can see there are a number of days being mis identified as DST days, but it doesn't seem like that would cause this? If both .Net and JS though they were DST days, then surely the end result should be correct?
Additionally, why is there a 2 hour difference between the output of ToUniversalTime and ToLocalTime during DST?
Here's a screenshot of JS processing a few dates duirng this problematic window
You can see that JS (or chrome?) is aware that during the 5th to the 27th of that year, Ireland is no longer on GMT+1 (even though it still says it's IST) so why is the date passed from VB an incorrect date? I though they both got their datetime information from the same source i.e. the host pc?

You appear to be running .NET on Windows, in which case .NET is using the Windows time zone data for your local time zone.
The Windows time zone data does not have the full history of time zone changes from all time. Microsoft's policy only guarantees historical data is present for dates from 2010 forward, though some time zones have historical data before then.
Conversely, Chrome is using time zone data from ICU, which uses IANA time zone data. IANA time zones have historical data since at least 1970, though many time zones have historical data before then.
With specific regard to Ireland, IANA has Irish time zone data going back to 1880. Windows has no history for Ireland at all, so it assumes the current rule has always been in effect. In reality, the current rule has been in effect since Oct 1968, so any dates before then will only have accurate time zone information in the IANA data.
If you run the same .NET code you showed above on Linux or MacOS, you'll see that .NET will use IANA time zone data on those platforms and your results will match up for 1958. Or, if you pick a more recent date your results will match on Windows too.
In short - don't run these sorts of tests on old dates and expect to get the same fidelity that you'll get with modern dates.
You also asked:
Additionally, why is there a 2 hour difference between the output of ToUniversalTime and ToLocalTime during DST?
Your date variables are all DateTime where .Kind is DateTimeKind.Unspecified. The IsDaylightSavingTime method will treat such values as if they belonged to the local time zone, as if they actually had DateTimeKind.Local. The same is true for the ToUniversalTime method, however, the ToLocalTime method will assume that DateTime values with DateTimeKind.Unspecified kind are actually in terms of UTC - as if they were DateTimeKind.Utc. Thus, when DST is in effect, date.ToUniversalTime() shifts an hour backward, and date.ToLocalTime() shifts an hour forward.
You can avoid such ambiguities by using DateTimeOffset instead of DateTime.

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)

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.

Difference between UTC, GMT and Daylight saving time in JS

I already read a lot of post and a little confused with UTC, GMT and daylight saving time.
Anyone can explain about javascript Date() object with UTC, GMT and daylight saving time.
The main point I want to know is, when we work with date, we need to think or not about daylight saving time.
And the calculation of UTC,GMT and daylight saving time is same or not in different kind of programming languages.

UTC is a standard, GMT is a time zone. UTC uses the same offset as GMT, i.e. +00:00. They are essentially interchangeable when discussing offsets.
All javascript (ECMAScript) Date objects use a time value that is UTC milliseconds since 1970-01-01T00:00:00Z. When the Date constructor is called without any arguments, it gets the time and time zone offset from the host system and calculates the time value. Therefore, the accuracy of the generated date depends on the accuracy of those components.
When outputting date values using the UTC methods (e.g. getUTCHours, getUTCMinutes, etc.), the vaules are UTC (GMT). When not using those methods (e.g. getHours, getMinutes, etc.) the host system time zone offset is used with the time value to generate "local" values from the UTC time value.
Whether daylight saving is applied or not depends on the host system settings. Whatever the current rules are for the host system time zone changes for daylight saving are applied to all dates, regardless of the actual offset that date (e.g. if currently DST starts on the first Sunday in October then it will be assumed to have always started on the first Sunday in October).
Date object behaviour is described in ECMA-262 §20.3.2 and a bit more clearly (for some parts) in MDN Date.