Daylight Saving Time, STK 12.2, and You

As some of you may know, STK has not always handled Daylight Saving Time gracefully when you used “local” date and time formats such as Gregorian Local (LCLG). In fact, sometimes you needed to follow specific instructions to avoid time discrepancies in your analysis.

Well, those of you who need to do analysis in local time zones have occasion to rejoice and immediately upgrade to STK 12.2! This version of STK introduces new DateTime formats which reliably solve local time zone issues, simply by telling STK what time zone you are in.

These new formats explicitly state the offset of your time zone from Universal Coordinated Time (UTC) in hours and minutes. Here they show the offset for Eastern Standard Time:

• GregorianLCLTimezone (LTZG):  21 Jun 2021 08:30:00.000-04:00 LTZG
• ISO8601YMDLCLTimezone (ISO-LTZ):  2021-06-21T08:30:00.000-04:00 ISO-LTZ

Having the offset in the text string means two important things.

First, yes, the UTC offset will now be present in every single DateTime value input or output — reports, graphs, the user interface, through the APIs, etc.

Second, these DateTime formats are continuous even when using Daylight Saving Time, which means they can handle ambiguous and invalid times.

Ambiguous times are times that are duplicated and thus unclear. For example, if I said let’s meet for late night waffles on Sunday, November 7, 2021, at 1:30 a.m., you would have to ask me “which 1:30 a.m.?” because there are two of them!

Invalid times are times that do not exist. For example, if I said let’s meet for late night waffles on Sunday, March 13, 2022, at 1:30 a.m., you may think I’m trying to stand you up, or that I live in the Twilight Zone, because that time will never occur!

However, the new DateTime formats have no trouble representing the continuous, unidirectional flow of time during these moments. Here’s an example of a how they look in the LTZG format:

Altitude of an elliptical satellite during “fall back” — the end of Daylight Saving Time and the resumption of Standard time.

Notice how 01:30 appears twice, but with different offsets.

Similarly, here’s the same report but during “spring forward” — the beginning of Daylight Saving Time.

Notice how the report skips right over 02:00 and the offset changes.

And one more example; here’s an access report for a facility to a satellite, right in the middle of the magical “spring forward” moment:

If you’re not paying attention to the offset in the times, you might think that STK is losing its mind and reporting that the pass lasts less than 15 minutes, when actually it’s more than an hour.

Using the new format

To use this new date format, STK needs to know which time zone you want to use. Note that when you launch STK, it automatically defaults to your system clock’s time zone. You can set this with the new Connect command, SetLocalTimeZoneName. It enables you to set the STK time zone independently of your system clock, using the same options and names.

Another new command, GetLocalTimeZoneName_R, returns the selected time zone name.

These new commands enable you do something like this with a custom application:

Here’s the code I used to put that together: