Sun Mar 30 03:00:00 CEST 2025
Sun Mar 30 01:59:00 CET 2025
Sun Mar 30 03:00:00 CEST 2025
Sun Mar 30 03:01:00 CEST 2025
2
1
2
2
Sun Mar 30 00:00:00 CET 2025
Sun Mar 30 00:59:00 CET 2025
Sun Mar 30 00:00:00 CET 2025 # <-
Sun Mar 30 00:01:00 CET 2025 # <-
Strange behaviour.
My request is simply having a nicer way (in scripting) of working with dates in UTC/Timezones.
Use Java's ZonedDateTime. Ignition's datetime objects are java.util.Date which are fundamentally UTC under the hood, with no attached time zone. Which means they always use the time zone of the JVM when parsing or printing. When you manipulate them with .addHours(), you are not making a time zone correction, but are altering the underlying UTC value. Don't use .addHours() to make time zone corrections.
We use something similar to that in our projects to get the correct utc (at least I think).
But... wouldn't be great to be able to have something like this? now() # returns current gateway time now_utc() # returns current utc time now_client() # returns current client time
And that the corresponding operations work with it's corresponding timezone.