Up through version 16.2 Windward handled a datetime data object as a UTC datetime (Java Date object). But mostly it just ignored all the issues around time zones and offsets. And 99% of the time that worked fine for everyone. Most programs ignore the issue and it tends to work as expected.
But there’s that 1%. And as data repositories start to actually store either an offset or timezone, this starts to become important. So with version 16.3 and later, Windward is now very timezone and offset aware. So what exactly is this.
Every datetime object is stored internally in a WindwardDateTime object. This Windward datetime holds the actual datetime internally in one of three types, depending one how it was passed in:
In the program, if no conversion is necessary, Windward works with the underlying type. A LocalDateTime can be formatted for output and as long as no offset or timezone is displayed in the string, works fine. If a LocalDateTime needs to be converted to an OffsetDateTime or ZonedDateTime, it is converted to UTC.
For data that has no explicit offset or timezone, with the exception of Excel, it is set to an OffsetDateTime with an offset of o (UTC). We do this because the convention for stored date objects is they are UTC. For a date in an XLSX file, it is set to a LocalDateTime because Excel defines the displayed date as the datetime in the local timezone.
We have also added macros to convert to/from local and UTC time. In addition there are macros to return the offset and timezone of a datetime object.
Finally, keep in mind that if you treat all data as in the local timezone (not UTC), and your app runs in that timezone, just leave everything alone and it should work fine. The program thinks all the data is UTC, but it writes it our as that datetime and so you are getting what you expect.