Today, we highlight a recent improvement integrated in the Night Explorer, and in fact, in all components where local time is computed: the correct management of the Daylight Saving Time periods, for all Observing Sites, and all dates, past, present and future…
Introduction
Dates and times are often a nightmare to handle for developers, because it is way more complicated than it is usually assumed. You may have some “fun” reading this blog post, for instance. We will focus on the DST for this article.
As you know, the Daylight Saving Time, a.k.a. the “Summer Time”, is a modern invention to advance clocks by one hour to (presumably) make better use of the longer daylight available during summer so that darkness falls at a later clock time. And lots of people really are upset about it, not only developers… (see this post, for instance).
The problem of course, is that this shift is not the same for every timezone, and its exact time of change is a political decision. Hence the date of offset change is changing every year. And… it occurs during the night! So how Arcsecond handles this?
The data source
We use the data freely available in timezonedb.com, which is reliable and regularly updated. In Arcsecond, we’ve put in place a mechanism to regularly check if the data integrated into our database (DB) is up-to-date. If it is not, admins receive a message and a semi-automatic process is performed to integrate the latest data inside Arcsecond DB.
Once the data is in, every Observing Site is updated. See for instance the La Silla Observatory in Chile: the value of UTC offset doesn’t change of course, since it is fixed with the timezone. But the values of the current DST offset value, and the next DST offset value, along the date at which the change will occur are updated.
Moreover, a batch of background tasks are being scheduled in the Arcsecond DB to ensure these values are automatically updated on the date of period change. For instance, at the time of writing, the next switch of DST value from 3600 seconds to 0 seconds for the La Silla Observatory (timezone “America/Santiago”) will occur on April the 6th, 2025.
Finally, we’ve also exposed three new API endpoints:
- https://api.arcsecond.io/timezones/ which exposes all worldwide timezones, each of them with its fixed UTC offset.
- https://api.arcsecond.io/timezones/america__santiago/ which exposes the details of a timezone (identified with its slug, here for the timezone “America/Santiago”), including the current DST period as of today, as well as the next one.
- And finally, all the periods (up to the year 2100) of the DST offset periods we know today for a given timezone: https://api.arcsecond.io/timezones/america__santiago/offsetperiods/
Pfiou! With that, we were ready to integrate the dynamic DST offset changes in our Night Views and everywhere else it is needed.
DST in the Times Bar and the Night Settings
If you open the Nigh Explorer today with its default AirmassCurves View, you will see two additions, outlined in red in the picture below.
On the top-right, inside the TimesBar, there is an indication of the current UTC and DST offsets, as of now, for the chosen Observing Site. This is the role of the TimesBar: to provide every relevant date and times for “now” at a given location.
If you click on the UTC+DST offsets, a short menu will show more details:
But of course, the date of the night itself can be freely chosen! You naturally want to see what the night looks like in the past or the future, when the DST offset may be different. Until now, the DST offset used was that of “now”, for the given site.
Today, the two offsets are decoupled. There is one for “now” in the Times Bar, and one dedicated to the views (AirmassCurves, StarTracks) and all date-specific components (see below).
Hence the second addition, in the bottom settings bar, outlined in red in the above picture. Likewise, when you click on it, you have more details, with 3 DST offset periods shown: the current one bracketed between the previous and the next.
Note how the label is displayed when the date chosen is precisely sitting on the DST offset change:
DST in the Night View Tracking and Ticks
DST offsets must be taken into account everywhere a “local” date is being displayed. Local here means local time for the chosen Observing Site, at the chosen date (and not the date of the computer). As you may expect, the local time jumps as expected when crossing an offset change during the tracking.
Look in the shirt video below how the DST offset and the local time correctly jumps from midnight to 1h hour when tracking is ON, while crossing the DST line:
Moreover, the ticks are correctly labelled, when the DST occurs during the night, along with a specific vertical line (dashed green; the ~vertical white line in the left is the Moon curve for that night):
DST in the Star Tracks and the Night Slider
When using the Star Tracks View, the bottom is occupied by the Night Slider, which has been updated to handle the DST change, both visually and in the time label. In fact, this is true in every other places in Arcsecond where the Night Slider is used (for instance when opening the side panel showing the details of a solar system planet, or in Skymaps).
Visually, we’ve added a little green vertical line to indicate the DST offset change:
And the local time label, whose value is updated, has an additional green label around the time of change:
Small Bonus
As a bonus, we have added two little “carets” on each side of the date input, in the bottom night settings bar. These buttons shift the date by one day, in one direction or the other. But if you press the Shift key at the same time, the date will jump by one week! Very convenient to adjust precisely the date of observations.
We may add these little carets in other places of date input…
Please, tell us below what you think of this DST support, and this type of article!
No responses yet