Sourcepro Enhanced-Time Zone Support Blog
August 23, 2022

Enhanced Time Zone Support in SourcePro 2022.1

Security & Compliance

With the release of SourcePro 2022.1, we significantly improved support for time zone information derived from the underlying operating system. This helps ensure applications written with SourcePro integrate easily with applications that rely on the operating system to provide time zone information. SourcePro 2022.1 enhances support for extracting time zone transition info from operating systems (including non-DST transitions), multiple sets of DST transitions in a single year, and detailed information about offsets and zone names that may vary over the lifetime of the zone.

Improved Support for non-DST Transitions

So what does this look like in practice? Let’s unpack an example.

RWZone::os() was originally designed to query the operating system to detect DST transitions. This worked well when time zones followed the POSIX time format. However, with modern time zone databases other transitions started to become commonplace. Unfortunately, RWZone::os() was unable to detect those sorts of transitions resulting in incorrect values. For example, in 1982 Singapore (which doesn’t observe DST) decided to change their time zone from a +07:30 offset to a +08:00 offset. This transition was unfortunately missed by RWZone::os(), resulting in the original offset being applied always:

RWDateTime dt{"1981-12-31T23:59:59", RWDateTime::iso8601};
cout << dt.asString(RWDateTime::iso8601) << endl;
dt.incrementSecond(1);
cout << dt.asString(RWDateTime::iso8601) << endl;

results in the following:

SourcePro 2021.1

SourcePro 2022.1

1981-12-31T23:59:59+07:30

1982-01-01T00:00:00+07:30

1981-12-31T23:59:59+07:30

1982-01-01T00:30:00+08:00

As you can see above, this was problematic. SourcePro 2021.1 was unable to detect the non-DST transition that occurred and continued to apply the historical offset. Since no other transitions were detected, the offset is applied using today’s dates. With SourcePro 2021.1, the non-DST transition is detected, and we apply the +08:00 offset from 1982 onwards. That’s a major problem solved by simply upgrading to SourcePro 2022.1.

Improved Support for Time Zones with Multiple DST Transitions

So what happens when multiple DST transitions are on the table? Let’s examine what happened before the upgrade and how SourcePro 2022.1 resolved the issue.

RWZone::os() made a second assumption from the era of POSIX time zone formats that there would only be two DST transitions per year (one transition to DST, and one transitioning from DST). As with non-DST transitions, this isn’t necessarily true in all time zones. In cases where multiple DST transitions occurred, RWZone::os() would fail to capture all of them properly. For example, in 2010 the Egyptian government decided to suspend Daylight Savings Time in observance of the month of Ramadan. This resulted in four DST transitions that year. With the old RWZone::os() implementation, only the first and last transition were detected properly:

RWDateTime dt{"2010-04-29T23:59:59", RWDateTime::iso8601};
cout << dt.asString(RWDateTime::iso8601) << endl;
dt.incrementSecond(1);
cout << dt.asString(RWDateTime::iso8601) << endl;

   

dt = {"2010-08-10T23:59:59", RWDateTime::iso8601};
cout << dt.asString(RWDateTime::iso8601) << endl;
dt.incrementSecond(1);
cout << dt.asString(RWDateTime::iso8601) << endl;

   

dt = {"2010-09-09T23:59:59", RWDateTime::iso8601};
cout << dt.asString(RWDateTime::iso8601) << endl;
dt.incrementSecond(1);
cout << dt.asString(RWDateTime::iso8601) << endl;

   

dt = {"2010-09-30T23:59:59", RWDateTime::iso8601};
cout << dt.asString(RWDateTime::iso8601) << endl;
dt.incrementSecond(1);
cout << dt.asString(RWDateTime::iso8601) << endl;

results in the following:

SourcePro 2021.1

SourcePro 2022.1

2010-04-29T23:59:59+02:00

2010-04-30T01:00:00+03:00

2010-08-10T23:59:59+03:00

2010-08-11T00:00:00+03:00

2010-09-09T23:59:59+03:00

2010-09-10T00:00:00+03:00

2010-09-30T23:59:59+03:00

2010-09-30T23:00:00+02:00

2010-04-29T23:59:59+02:00

2010-04-30T01:00:00+03:00

2010-08-10T23:59:59+03:00

2010-08-10T23:00:00+02:00

2010-09-09T23:59:59+02:00

2010-09-10T01:00:00+03:00

2010-09-30T23:59:59+03:00

2010-09-30T23:00:00+02:00

In SourcePro 2021.1, only the first and last DST transition of the year were detected. The transition back to standard time during the month of Ramadan and the resumption of DST afterward were missed. With SourcePro 2022.1, multiple DST transitions within a single year or across multiple years can be detected and accounted for correctly.

Performance Implications With Time Zone Enhancement

Increases in precision like this normally come with a cost. Querying additional fields and capturing additional data for each zone transition should theoretically take extra computing resources, and in some cases querying these new data structures should take additional time.

Fortunately, this isn’t the case with SourcePro 2022.1.

The team invested extra effort in optimizing the search algorithms, data structures and overall approach. This ensures performance wasn’t negatively affected as we expanded our support. In fact as a result of these optimizations, we’ve seen an increase in performance for common operations. Here’s how the update impacts a few common operations:

Startup Performance

RWZone::os() will examine the operating system the first time that it is called in order to populate its internal zone database. This is executed once, so it does not have an ongoing performance impact, however it can affect the performance of short-lived applications.

SourcePro 2022.1 Blog - 1
SourcePro 2022.1 Blog - 2

Date/Time Formatting Performance

The most common scenario where RWZone information is used is in converting an RWDateTime to its calendar components (year, month, day, etc.), and vice versa. In SourcePro 2022.1, we’ve improved the interface between RWDateTime and RWZone to make these calculations simpler and faster.

SourcePro 2022.1 Blog - 3
SourcePro 2022.1 Blog - 4
SourcePro 2022.1 Blog - 5
SourcePro 2022.1 Blog - 6

Other Enhancements in SourcePro 2022.1

In addition, SourcePro 2022.1 contains several other significant improvements, including:

  • Enhanced handling of struct tm parameters to indicate whether they represent standard or daylight savings time (i.e., tm_isdst is set to 0 or 1 respectively). Previously this information was ignored, resulting in ambiguous or incorrect results, especially when compared to the behavior of mktime.
  • Support for OpenSSL 3.0. Applications written with SourcePro can now take advantage of the latest production-ready encryption and security.
  • Support for Microsoft Windows 11 and Microsoft Visual Studio 2022. SourcePro applications can now target the latest operating systems and compilers available from Microsoft.
  • Numerous other bug fixes and enhancements make this the most secure, stable, and performant SourcePro release available.

Upgrade today or request an evaluation to try out all that SourcePro 2022.1 has to offer.

Request Evaluation