Date: Thu, 28 Mar 2024 17:43:10 +0000 (UTC) Message-ID: <1453405791.10729.1711647790528@911f0a1bad02> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_10728_1182390648.1711647790528" ------=_Part_10728_1182390648.1711647790528 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
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 repres= ent 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 form= at it. And the toString() of a date already formats it, so yes it shows the= re 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[, second=
s[, milliseconds]]]]]);
Those arguments are then the hours in your t=
imezone. Just like if you would format the string with "yyyy/MM/dd HH:mm" w=
ith 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 millis= econds 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 d= ate in your timezone will be 12.
In Servoy the problem arises when you are calling&nb= sp;Date#getHours() = (and other methods like that) because that is in local time. And your serv= er could be in in the timezone +2 but your client could be in +3, and servo= y code runs at the server, so the getHours() call will be the hours that th= e server reports it (the same is the toString())
var date1 = =3D new Date(2019,10,1,12); =09var date2 =3D new Date(Date.UTC(2019,10,1,12)); =09application.output(date1) =09application.output(date2) =09application.output(date1.getHours()) =09application.output(date2.getHours())=20
The above code will print a different hours dependin= g on the offset you have to UTC. So "date1" will just print "12" in b= oth 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 U= TC or +1 but +2)
For getting the hours that the client has (NG and Sm= art) you can use the utils.dateFormat
application.out= put(utils.dateFormat(date1,"HH"));=20
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 NGC= lient 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. (Amsterda= m compared to Athens)
For displaying stuff in the client we he have for NG= Client an option to Use as LocalDateTime in the date format dialog. By defa= ult if that is not checked we send the date over in a ISO-8601 dateformat l= ike: 2019-11-01T12:00:00+01:00 if the server is in +1 . So we send ove= r the date in the servers format but we also give the timezone where we for= matted this date in. This information is received by a client and if that i= s 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 onl= y "conversion" that is done here is that the same milliseconds is formatted= differently based on a different timezone (so the toString of the date cha= nges, not the Date itself)
Now if you have not calendar times but more like a b= irthday (you want to just specify a day in a year not time) then you should= check "Use as LocalDateTime" this means that where ever you go the date sh= ould 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 prese= nted to will just be 2019-11-01 12:00 without any "conversion" a= s it seems.
Problem is that now we do convert, because now if yo= u would ask the getTime() in milliseconds from it, it would be different, i= t would be 1 hour in milliseconds less. Because we kind of removed 1 hour f= rom it (the difference between the server +1 and the clients +2)
So now the formatted date stays the same (no "conver= sion" here) but the actual date did change because now it represents that s= ame 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 th= e server knows that for that property it should use LocalDateTime and will = just ignore or not that timezone information based on that boolean.
If you are using "Use as LocalDateTime" then it coul= d be that you want to make the date object that must be really in "today" o= r "now" on the client. So the same thing as doing a new Date() in the brows= er and then sending that to the server that ignored the timezone.
To do the same thing that you really are in the "now= " on the client you can use application.getTimeStamp() this will create a d= ate that will be in the same day as the browser. as an example new Date() o= n the server that is in +1 would generate 2019-28-11 23:00 then applic= ation.getTimeStamp() would generate if the client was in +2 a date string o= f 2019-28-12 00:00. Which is really the time that that client is in at that= time.
If you want to search between 2 dates, like searching for everything of = yesterday, but then you mean everything of what the users means of yesterda= y. You need to make dates that for that user is yesterday. Whic= h could be dates like: "2019-28-10 00:00" and "2019-28-10 23:59", but those= times are client times so in the current example in timezone +2. But the s= erver is in +1 , and the server will do the searching if it does that with = the 2 dates above as is then it would be searching for stuff that is in the= "yesterday" of the server. So you need to convert or create them first to = the times of the user:
=09var startDat= e =3D utils.parseDate("2019-11-28 00:00","yyyy-MM-dd HH:mm", null) =09var endDate =3D utils.parseDate("2019-11-28 23:59","yyyy-MM-dd HH:mm", n= ull)=20
This parseDate with 3 arguments is new in Servoy 201= 9.12, the 3rd argument can also be a TimeZone ID like "GMT+3" but if it is = null it will use the clients timezone, the standard 2 arguments will use th= e servers timezone.
The output of that if the server is in +1 and the cl= ient is in +2:
Wed Nov 27 23:00:00 CET 2019
Thu Nov 28 22:59:00 =
CET 2019
(dates printed/formatted in +1/CET)
If these 2 timestamps would be send to the client (U= se as LocalDateTime as false), then the browser will "add" (formats it in i= ts timezone) the time difference (1 hour) back on to it and it will then re= present the exactly that day.