Working with Dates (and timezones)

First of all the constructor new Date() will make the same date no matter what timezone you are in..

So if you do new Date() in The Netherlands and at the same time somebody else does new Date() in USA. then that is the exact same date, both represent the time in milliseconds after 1970 in UTC. This is called Unix Time.

The only thing that makes is different is that when you print it or format it. And the toString() of a date already formats it, so yes it shows there the date and timezone that you are currently in. But this does not mean that Dates have a timezone, that is not correct.

The date object has a constructor as: 

new Date(year, month[, day[, hour[, minutes[, seconds[, milliseconds]]]]]);

Those arguments are then the hours in your timezone. Just like if you would format the string with "yyyy/MM/dd HH:mm" with your timezone given to the formatter.

The Date object has another function Date#UTC(year,month,date,hrs,min,sec,ms) that one you will give back the milliseconds that is in UTC (you can wrap this number in a new Date(number) again). So if you give that function a "hrs" of 10 and you are in +2, then the date in your timezone will be 12.

In Servoy the problem arises when you are calling Date#getHours()  (and other methods like that) because that is in local time. And your server could be in in the timezone +2 but your client could be in +3, and servoy code runs at the server, so the getHours() call will be the hours that the server reports it (the same is the toString())

var date1 = new Date(2019,10,1,12);
	var date2 = new Date(Date.UTC(2019,10,1,12));
	application.output(date1)
	application.output(date2)
	application.output(date1.getHours())
	application.output(date2.getHours())

The above code will print a different hours depending on the offset you have to UTC.  So "date1" will just print "12" in both outputs because you constructed it for your local time, if you are in +1 then "date2" will print "13" in both scenario's, because the "local utc (London)" time of "12" is "13" in your local time zone (Amsterdam)

But the above will do this all with the timezone the server is in, not the actual client which can be different again (so not UTC or +1 but +2)

For getting the hours that the client has (NG and Smart) you can use the utils.dateFormat

application.output(utils.dateFormat(date1,"HH"));

That will use the timezone of the client that we got from the browser. And for example if the server would be in +1 and the NGClient would be in +2 then the above code would print "13". Because "12:00" in the servers timezone is for the clients timezone 1 hour later. (Amsterdam compared to Athens)

For displaying stuff in the client we he have for NGClient an option to Use as LocalDateTime in the date format dialog. By default if that is not checked we send the date over in a ISO-8601 dateformat like: 2019-11-01T12:00:00+01:00 if the server is in +1 . So we send over the date in the servers format but we also give the timezone where we formatted this date in. This information is received by a client and if that is in +2 the time that the client will display that same date will be:  2019-11-01 13:00, because it knows that that give date was for +1 and it is in +2 so it must add 1 hour to the displayed time (still the time in milliseconds does not change! this is purely a formatting thing)

This is logical because a calendar datetime of 12:00 in +1 (server timezone) is in +2 (client timezone) 13:00.  So the only "conversion" that is done here is that the same milliseconds is formatted differently based on a different timezone (so the toString of the date changes, not the Date itself)

Now if you have not calendar times but more like a birthday (you want to just specify a day in a year not time) then you should check "Use ass LocalDateTime" this means that where ever you go the date should be treated the same (formatted).  What this means is that instead of sending over the date string as: 2019-11-01T12:00:00+01:00 we send it over without a timezone info: 2019-11-01T12:00:00 this means that the client can only assume this date is in its timezone (so it assumes 2019-11-01T12:00:00+02:00). Then the formatted time that the user is presented to will just be  2019-11-01 12:00 without any "conversion" as it seems.

Problem is that now convert. because now if you would ask the getTime() in milliseconds from it, it would be different, it would be 1 hour in milliseconds less. Because we kind of removed 1 hour from it  (the difference between the server +1 and the clients +2)

So now the formatted date stays the same (no "conversion" here) but the actual date did change because now it represents that same formatted (server) time in a different timezone so it needed to adjust the milliseconds.

The browser if it changes the date and we send over the date string again it will always just send over the timezone info with it, sending it always in the format: 2019-11-01T13:00:00+02:00, but the server knows that for that property it should use LocalDateTime and will just ignore or not that timezone information based on that boolean.