Most of us in North America and the Caribbean are getting ready to “spring forward” this weekend, with many more countries around the world set to follow suit over the next few weeks.
Daylight Saving Time (not to be confused with Daylight SavingS Time) officially begins for the US on Sunday, March 8, at 2am. Unless you are in Arizona. Or Hawaii. At 02:00, clocks in cell phones, computers, and all kinds of other electronics will immediately jump ahead to 03:00. Which means, that by societal convention, 2am won’t actually exist on March 8… at least when using the local time scale.
Have you ever wondered how STK handles this event? If you’ve ever needed to report event times in a local time rather than universal time (UTC, aka Zulu) you should.
STK offers some local time options as described in the Help, such as Gregorian Local (LCLG), Julian Local (LCLJ). The Help states:
“The local time offset from UTC changes between local Standard Time (LST) and local Daylight or Summer Time (LDT) as determined by the computer hosting STK.”
However, the way this plays out in the software is not really explained.
You have likely noticed that for Windows systems, you have the option of setting a local time zone.
You may have also noticed the option on this page to “Adjust for daylight saving time automatically”.
It turns out that Microsoft monitors DST announcements by global governments and puts them into Windows Updates. Make sure your Windows is up-to-date!
So, you may be thinking: “Great, so STK gets local time from Windows. Windows knows about Daylight Saving Time because Microsoft does the work of tracking and implementing global DST schedules. Everything will always work perfectly for me, no matter where in the world I use STK, and I didn’t have to do a thing!”
And unfortunately, you would be wrong.
As it turns out, STK handles Daylight Saving Time about as smoothly as your pets and small children handle it.
Whenever STK is asked to compute a local time, it simply asks the system clock for the current UTC time offset, and applies that to all date calculations. Consider this simple scenario of a default satellite with a default sensor, which happens to be heading northeast off the coast of Japan (toward the bottom left of the image) at the time DST hits the US Pacific time zone, March 8, 2020 at 02:00
When I compute accesses from the sensor to each of those locations in UTCG, I get the following:
Which looks good – no abrupt changes in the hour. Now when I simply change the units on that same report to LCLG and refresh, I get this:
When I ran the scenario today (Friday, March 6), STK asked my system clock what my current time zone is, and what its current offset is from UTC. I’m currently in Pacific Standard Time, which is UTC -8 hrs. So, for example, take the instant of time at 8 Mar 2020 10:00:00.000, subtract 8 hrs, and you have 8 Mar 2020 02:00:00. Notice anything? That’s right, your local government may have decreed that 02:00:00 – 02:59:59 should be ignored on this date.
Now, let’s look at what would happen if I opened this same scenario on my same computer and did the exact same set of steps, but on Monday, March 9 2020:
See the difference? Now when STK queries my system for the UTC offset, it is getting -7 hours (-8hr + 1hr springing forward). So ~10:00 – 7 hrs = ~ 03:00. You’ll note that this is exactly the same behavior as if I had simply changed my time zone, restarted STK, and reran the report. In fact, this is what I did for the test – I don’t recommend changing your system date and time ahead a few days and then back, even if your IT policy allows it. It can lead to all kinds of problems!
One way to think of this is that when your system clock is in Standard Time, STK’s local time format acts as though Daylight Saving Time does not exist, has never existed, and never will exist. Some of you reading this are rejoicing at that thought. However, the inverse is also true – when your clock is in Daylight Saving Time, that’s all STK has ever known and will ever know.
So what is the STK analyst to do? Well, you have a few options, depending on your analysis situation:
- Don’t use Local! Seriously, stick to UTC, it’s a lot more foolproof in general. But if you have to use Local…
- Does your analysis timeframe occur entirely during Standard or Daylight Saving Time? Then use your system time zone to your advantage. You can safely work in local time, as long as nothing in your scenario is crossing that boundary. Just be mindful that if your system clock is not currently in the same time scale as your analysis, you may need to change your time zone settings temporarily to reflect that.
Example: George is working in Washington, DC and is asked on Friday, March 6, 2020 for his local ISS pass times for when his niece Sally visits during spring break week, April 6-10. If he computes them using his normal time zone setting of Eastern Standard Time, come April, they’ll miss the ISS by an hour. Sally will be sad and dejected and may give up on her dream of being an astronaut.
However, if George briefly changes his time zone to Atlantic Time (UTC-4) while computing the analysis, they’ll see the ISS, Sally will be inspired to follow her dreams, and perhaps become the first woman to walk on Mars.
Does your analysis timeframe cross the DST boundary, as in my scenario above? Then you can either:
- Compute results UP TO the DST boundary, then change the time zone, then compute the rest of the results AFTER the boundary. You may need to manually post-process the results to merge them. For my scenario above, this could then look something like:
- Report all analysis in UTC, and then write a script to convert from UTC to local time, taking into account your local system’s timezone and its DST transitions (or lack thereof). Many programming languages have structures that can help you deal with this, for example C# has the TimeZoneInfo and DateTimeOffset objects. Here is short snippet showing one way you could use them:
TimeZoneInfo localZone = TimeZoneInfo.Local;
//DataSets here is the “Access Data//Start Time” data provider
string AccessStartUTCG = AccessInterval.DataSets.GetValues().GetValue(Access).ToString();
//the DateTimeStyles.AssumeUniversal means the input time must be in UTCG
DateTimeOffset AccessStartDTOutcg = DateTimeOffset.Parse(AccessStartUTCG, CultureInfo.InvariantCulture, DateTimeStyles.AssumeUniversal); Console.WriteLine(AccessStartDTOutcg.ToLocalTime().ToString());
DateTime AccessStartDTutcg = DateTime.Parse(AccessStartUTCG);
The output of this for the access start and stop time of a pass which spanned the DST transition would look something like:
3/8/2020 1:50:51 AM -08:00
3/8/2020 1:50:51 AM
3/8/2020 3:00:06 AM -07:00
3/8/2020 3:00:06 AM
- Are you stubborn and independent? Then try what a colleague of mine from many years ago did: choose to personally not observe Daylight Saving Time and keep your clocks right where they are. This will sure simplify your interaction with STK, but it may complicate your interactions with others…
Don’t forget to set your clocks ahead Saturday night!