I am just trying to get a string that reports the current Time zone offset aka "+1000" or "+1100" I have already resorted to a function and this is not making sense, I suddenly have offsett of -600, yet a time stamp returned is displaying +1000 which is correct. Thought I could extract it as string using the toLocaleString(...) method but it returns the decimal timestamp converted to a string! And why does debug convert the .getTimezoneOffset() to hex when I expand it. Nothing working as I should and have trouble finding a reference website on the Date() class.
Even posting this is getting weird! So sorry if it looks funny
msg.payload = Math.round(+ new Date());
return msg;
The reason you are getting local time from such functions as Date.getHours() is because the definition of those functions is specifically to give you the hours in local time. It converts the milliseconds ticks (UTC) into the local time for you.
As I often say to people, you are much better off working in UTC except for where someone inputs a time or needs to see a time. It avoids soooo many processing issues.
To get the '+0100' part of a dateTime string the function below will work.
If date.toString() does not return something like Wed Apr 10 2024 17:33:46 GMT+0100 (British Summer Time) you will have to adjust GMT to whatever comes before the time zone offset.
I agree, NR and Mosquito all run a Raspi on my local network, the Raspi and router which is a NTP server displays correct time. so not sure why I got -600 instead of +1000. THanks anyway
Thanks all, it appears I was expecting the .getTimezoneOffset() to return a TZ string aka "+1000" but appears to return it as -ve minutes wrt Zulu (-600). would have sussed that if I had found usable documentation (developer.mozilla.org was useless!) last night but was late. I have now found it in W3schools, not quite complete but it has most.
I first tried Steve McL code and it works. I will have to wait until October to verify it does shift to Summer time but expect it will.
This is exactly what I said earlier in the thread. I got the info from MDN so maybe not so useless. I also showed how to get the actual timezone (not the offset). The offset could, of course, be derived from the number of minutes from UTC.
Reminds me of the time I was given a dataset to analyse, covering ten hours or so but with an unknown time zone setting. Nobody could help, but I did find a value within the dataset that was probably following (approximately) the ambient temperature. I did know where the data was measured, so I found the closest airfield and downloaded the aftercast for the approximate time span. A bit of judicious correlation-by-eye and I had the time zone offset. But there are easier ways…