Paraguay may adopt permanent DST soon

Today the Congress of Paraguay passed a bill to observe UTC-3 permanently, equivalent to permanent DST. The bill still needs to be approved by the president. https://www.abc.com.py/politica/2024/09/24/congreso-sanciona-horario-de-vera... The text of the bill says that it would enter into force on the first Sunday in October 2024, the same date currently scheduled to start DST. But in practice, it would only make a difference from the fourth Sunday of March 2025, the date currently scheduled to end DST. https://silpy.congreso.gov.py/web/expediente/132531

President Santiago Peña confirmed today that he will sign the bill. Source: https://www.ip.gov.py/ip/2024/10/04/ejecutivo-confirma-que-promulgara-ley-de... Best regards, Even Scharning Founder & developer Time.is - exact time for any time zone

On 2024-10-04 11:07, Even Scharning via tz wrote:
President Santiago Peña confirmed today that he will sign the bill.
Thanks for the heads-up. I installed the attached patch into the development repository. It assumes that the bill will indeed be (or has indeed been) signed into law. This change doesn't affect timestamps until March so there's no rush for a new TZDB release. Although the bill says it takes effect tomorrow, it's possible that its late signing means it's not officially law until after that. If we find out when that is, we can update TZDB accordingly. That would be only a minor change, as it'd affect only tm_isdst flags which are obsolescent and nobody should care about them.

The president approved the law on 11 October 2024, and it was officially published on 14 October 2024. https://www.gacetaoficial.gov.py/index/detalle_publicacion/89723 The text of the law says that it enters into force on the first Sunday in October 2024 (6 October 2024). But the constitution prohibits retroactive effect, and the civil code says that laws enter into force on the day after their publication or on the day that they specify, and it also says that they don't have retroactive effect. So I think that the time change on 6 October 2024 should still be considered as DST according to the previous law, and permanently UTC-3 from 15 October 2024 according to the new law. But in practice it doesn't matter. https://www.constituteproject.org/constitution/Paraguay_2011 https://www.oas.org/dil/esp/codigo_civil_paraguay.pdf

Heitor David Pinto wrote:
The text of the law says that it enters into force on the first Sunday in October 2024 (6 October 2024). But the constitution prohibits retroactive effect, and the civil code says that laws enter into force on the day after their publication or on the day that they specify, and it also says that they don't have retroactive effect. So I think that the time change on 6 October 2024 should still be considered as DST according to the previous law, and permanently UTC-3 from 15 October 2024 according to the new law. But in practice it doesn't matter.
Regardless of what the constitution or civil code says, it's a bit silly to imagine that a law could be passed to change what time it was in the past. I don't think even Niyazov in Turkmenistan tried that. -- Doug Ewell, CC, ALB | Lakewood, CO, US | ewellic.org

On Mon, 14 Oct 2024 at 20:34, Doug Ewell via tz <tz@iana.org> wrote:
So I think
that the time change on 6 October 2024 should still be considered as DST according to the previous law, and permanently UTC-3 from 15 October 2024 according to the new law. But in practice it doesn't matter.
Regardless of what the constitution or civil code says, it's a bit silly to imagine that a law could be passed to change what time it was in the past.
That's not what's at issue (though if it were, we would of course endeavor to describe whatever was observed *de facto*, rather than *de jure*). In this case, there is no dispute as to what time Paraguay has observed between 6 and 14 October 2024 (inclusive), and that is UTC-3. The only potential difference is the value of the obsolescent "isdst" bit and, as Heitor said, "in practice it doesn't matter": For dates beginning with the 6 October 2024 forward clock shift but prior to the new law taking effect, we would typically have continued to model this as a standard offset of UTC-4 plus 1 hour of DST. For dates after the law takes effect, we generally model "permanent DST" instead as a standard offset of UTC-3 with no DST. Paraguay is, of course, not actually shifting any clocks when the law officially takes effect (be that on 15 October or otherwise), because they already did that on 6 October under the old law. Meanwhile, the technical difference here between UTC-4+1 and UTC-3+0 is inconsequential to most. Since all timestamps between these dates are the same under both the old law and the new one, the intent of the new law could still be fully observed, just as it had been telegraphed. While there is value in recording these exact details of the letter of the law, that value is mostly in our commentary. It may be overly confusing for us to encode a separate "isdst"-only "transition", as the new law had no practical effects which were affected by the few "extra" days it took to codify it. The actual wall-clock effects of the new law, which are our primary concern, won't happen until the night of 22/23 March 2025, when Paraguay will no longer "fall back" to UTC-4. -- Tim Parenti

Tim Parenti wrote:
Regardless of what the constitution or civil code says, it's a bit silly to imagine that a law could be passed to change what time it was in the past.
That's not what's at issue (though if it were, we would of course endeavor to describe whatever was observed de facto, rather than de jure). In this case, there is no dispute as to what time Paraguay has observed between 6 and 14 October 2024 (inclusive), and that is UTC-3. The only potential difference is the value of the obsolescent "isdst" bit and, as Heitor said, "in practice it doesn't matter":
Yes, I apologize. In responding to the perceived absurdity, I lost track of what the actual change was. -- Doug Ewell, CC, ALB | Lakewood, CO, US | ewellic.org

* Tim Parenti via tz:
That's not what's at issue (though if it were, we would of course endeavor to describe whatever was observed de facto, rather than de jure). In this case, there is no dispute as to what time Paraguay has observed between 6 and 14 October 2024 (inclusive), and that is UTC-3. The only potential difference is the value of the obsolescent "isdst" bit and, as Heitor said, "in practice it doesn't matter":
Why do you say that the isdst bit is obsolete? The glibc implementation uses in ways that significantly alter application behavior. Thanks, Florian

On 2024-10-28 06:04, Florian Weimer via tz wrote:
Why do you say that the isdst bit is obsolete? The glibc implementation uses in ways that significantly alter application behavior.
tm_isdst was intended for use as an index to the external tzname array. This use is obsolete. Apps that use tzcode or glibc or any other implementation that conforms to POSIX.1-2024 should use struct tm's tm_zone member instead, as tzname does not work for geographical zones, which can have more than two abbreviations. And even apps running on older implementations that conform only to POSIX.1-2017 or earlier should use strftime "%Z" rather than tzname and tm_isdst. The only remaining non-obsolete use of tm_isdst is as a hint to mktime. However, this works only for the proleptic TZ settings like TZ='<-04>4<-03>,M10.1.0/0,M3.4.0/0' required by POSIX.1-2017 and earlier. It does not work in general for geographical settings like TZ='America/Asuncion', because these settings can and do have more than two UT offsets. Although this topic is discussed in theory.html, I see the discussion could be improved a bit and installed the attached.

* Paul Eggert:
On 2024-10-28 06:04, Florian Weimer via tz wrote:
Why do you say that the isdst bit is obsolete? The glibc implementation uses in ways that significantly alter application behavior.
tm_isdst was intended for use as an index to the external tzname array. This use is obsolete. Apps that use tzcode or glibc or any other implementation that conforms to POSIX.1-2024 should use struct tm's tm_zone member instead, as tzname does not work for geographical zones, which can have more than two abbreviations. And even apps running on older implementations that conform only to POSIX.1-2017 or earlier should use strftime "%Z" rather than tzname and tm_isdst.
It's not fringe because gmtime and localtime set tm_isdst to a non-negative value. Apparently it's common in applications to feed back those broken times into mktime without resetting tm_isdst. The current glibc behavior continues to be a problem for us, I think. Thanks, Florian

On 2024-10-28 09:47, Florian Weimer wrote:
It's not fringe because gmtime and localtime set tm_isdst to a non-negative value. Apparently it's common in applications to feed back those broken times into mktime without resetting tm_isdst.
You're right that tm_isdst not "fringe", as it's required by ISO C and by POSIX. Nonetheless tm_isdst is obsolete except as a hint for mktime, and even there the hint does not work in general in the common case where TZ is a geographical timezone. The particular case that started this thread is whether tm_isdst should be zero or positive for TZ="America/Asuncion" during the period from October 6 through October 15 of this year[1]. This is one of the cases where the behavior of tm_isdst is not specified (or even hinted at) by any standard, and regardless of whether tm_isdst 0 or positive it will not work for common uses of mktime. More generally, tm_isdst's value does not matter for any part of tzdata. When a geographical timezone is used, no application should depend on whether tm_isdst is zero or positive, and no standard tries (or should try) to specify this. [1]: https://lists.iana.org/hyperkitty/list/tz@iana.org/message/BIZ3YBJBVBLCSVIY4...

On 10/14/24 18:45, Heitor David Pinto via tz wrote:
I think that the time change on 6 October 2024 should still be considered as DST according to the previous law, and permanently UTC-3 from 15 October 2024 according to the new law.
Thanks, I installed the attached further patch so that tm_isdst changed from 1 to 0 today. As you mentioned, this is an unimportant patch since it affects only tm_isdst. What matters is that we publish a new TZDB release well before March, when the main Paraguay change occurs. We can include in that release any other changes that come down the pike soon in the Philippines or Ukraine or whatever.

As you mentioned, this is an unimportant patch since it affects only tm_isdst. What matters is that we publish a new TZDB release well before March, when the main Paraguay change occurs. We can include in that release any other changes that come down the pike soon in the Philippines or Ukraine or whatever.
Please take into account that in some applications timezone rules are used well before the timezone rule change date. For example, I am writing from the flight metasearch website Trabber.com and we use timezones to calculate flight durations. So currently all flights to/from Paraguay from April 2025 onwards are displayed with a wrong duration because our TZDB is not updated yet. Is there an estimated date when this change will be published? Is there a way to get the current, most up to date version of the TZDB from your website? We are using this one: https://www.iana.org/time-zones/repository/tzdata-latest.tar.gz but it does not contain Paraguay timezone change. Thanks a lot for your help.

On 2024-12-20 01:10, ofrias--- via tz wrote:
As you mentioned, this is an unimportant patch since it affects only tm_isdst. What matters is that we publish a new TZDB release well before March, when the main Paraguay change occurs. We can include in that release any other changes that come down the pike soon in the Philippines or Ukraine or whatever.
Please take into account that in some applications timezone rules are used well before the timezone rule change date.
It is up to civil political administrations to take into account required considerations, including notification lead time, as they are mandated by international aircraft operating scheduling rules to publish notices of any time changes with adequate lead time. If civil political administrations do not publish notices of any time changes with adequate lead time, they are punished by penalties of millions of taxpayer money (backed by the threat of stopping scheduling flights into their territories), depending on the impact of any disruption to schedules, and likely business impacts of reschedulings and cancellations of many flights, as airports and airlines, and their operational systems, can not be changed nor change their operations, as quickly as politicians change their minds, after failing to make up their minds for months!
For example, I am writing from the flight metasearch website Trabber.com and we use timezones to calculate flight durations.
Trip durations depend only on route locations and directions not clock times and should be fixed - except for real time operational, weather, and "traffic" disruptions - they should never be calculated! Departure times should be stored only for trip origin locations, in local or UTC depending on whether the departure occurs at a fixed local or UTC time, and in the latter case, changes after DST changes. See the IATA SSIM guidelines and notices for airlines, airports, and civil authorities regarding scheduling and notifications requirements and best practices.
So currently all flights to/from Paraguay from April 2025 onwards are displayed with a wrong duration because our TZDB is not updated yet.
What really matters is whether route origin location times change after any timezone change, if schedules are fixed in UTC, or they depend on origin or destination location business considerations or airport services availability.
Is there an estimated date when this change will be published?
Is there a way to get the current, most up to date version of the TZDB from your website? We are using this one: https://www.iana.org/time-zones/repository/tzdata-latest.tar.gz but it does not contain Paraguay timezone change.
You should have your own process to test changes based on the data in the tzdb development repository, which contains all changes pending release: https://github.com/eggert/tz plus any changes that you may become aware of, and issues that occur during testing. For more information, see: https://data.iana.org/time-zones/tz-link.html -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry

Thanks a lot for all the information. I am sure IATA, airlines and OTAs use other systems to handle the timezone information. But in our case we rely on TZDB for this. We connect to airline and OTA APIs that in most cases do not provide flight duration information. We only get flight departure and arrival times and with these local times (maybe in different timezones) we calculate flight durations. This is why we are currently impacted by Paraguay timezone rules change, because the airlines are using the updated rules while our system is (was) not yet updated. Any system that works with future events that has to convert them between UTC and local time, or between different time zones is impacted by not having the right rules for the next months. In our case we handle events (flights) up to more than one year in advance. So, my point was, do not think that it is OK as long as you publish the TZDB with enough time for its propagation to the operating systems, Java, etc. The sooner we get the updated rules the better for this type of application handling future events. We have manually ported Paraguay rule to our TZDB thanks to the development repo that you linked. Thanks a lot for your help. On Fri, Dec 20, 2024 at 9:24 PM Paul Eggert <eggert@cs.ucla.edu> wrote:
On 2024-12-20 00:10, ofrias--- via tz wrote:
Is there an estimated date when this change will be published?
We should publish the next TZDB release sooner rather than later, because of Paraguay. We don't have an estimated date, though.

But aren't we always asking for at least 6 months lead time for the changes to propagate correctly? I think the update should be out as soon as possible, given the March change in the rules. Abrazo, Carlos Perasso On Fri, Dec 20, 2024 at 5:25 PM Paul Eggert via tz <tz@iana.org> wrote:
On 2024-12-20 00:10, ofrias--- via tz wrote:
Is there an estimated date when this change will be published?
We should publish the next TZDB release sooner rather than later, because of Paraguay. We don't have an estimated date, though.

On Sat, 21 Dec 2024 at 07:50, Carlos Raúl Perasso via tz <tz@iana.org> wrote:
But aren't we always asking for at least 6 months lead time for the changes to propagate correctly?
Since September 2020 <https://github.com/eggert/tz/commit/241e6df0731f0e8d2a07a7ac42878f00086bd642>, our formal guidance has requested at least a year's notice.
I think the update should be out as soon as possible, given the March change in the rules.
A main reason for our guidance on lead time is that there is always a balance between promulgating changes quickly and grouping several changes together in a single release. Both goals are meant to ease overall downstream burden, but in different ways. Since we can't predict the future, it just comes down to an ongoing series of judgement calls. Paraguay's change came to us at the height of the traditional "silly season". As is typical of said season when one particular change isn't immediately urgent, there were good reasons to wait at the time; namely, Brazil and Ukraine were simultaneously mulling changes that would have taken effect at similar or earlier times. They have since opted not to make those changes, so the balance has now shifted back toward cutting a release sooner. But there are still some smaller things pending: We haven't heard anything more about the proposed legislation in the Philippines since August; since it could have effects from 1 January, it may make sense to wait a few more days to see whether that re-materializes or not. A new IERS Bulletin C (expected not to introduce a leap second in June 2025) will also arrive in early January; all else equal, including that could buy a new release extra validity time ahead of likely DST discussions in the US early next year. And, of course, while I can't speak for Paul's personal schedule, one must remain mindful of folks' time as we enter the festive season: Releases invite more bug reports from a wider audience which can sometimes require another release on a quick turnaround. (You can help here by testing in advance!) These kinds of highly fluid reasons are why we don't commit to timelines for any specific release. But hopefully illustrating them (non-exhaustively) above demonstrates that our target is indeed "not much longer" and will help assuage concerns. -- Tim Parenti

Hi, Is it possible to include Paraguay's change in the next release? I understand the "silly season" implications, but given the fact that the change comes in the form of a Law, not a Decree, it's quite difficult for it to revert before March. https://silpy.congreso.gov.py/web/descarga/ley-144874 Un abrazo, Carlos On Sat, Dec 21, 2024 at 1:28 PM Tim Parenti <tim@timtimeonline.com> wrote:
On Sat, 21 Dec 2024 at 07:50, Carlos Raúl Perasso via tz <tz@iana.org> wrote:
But aren't we always asking for at least 6 months lead time for the changes to propagate correctly?
Since September 2020 <https://github.com/eggert/tz/commit/241e6df0731f0e8d2a07a7ac42878f00086bd642>, our formal guidance has requested at least a year's notice.
I think the update should be out as soon as possible, given the March change in the rules.
A main reason for our guidance on lead time is that there is always a balance between promulgating changes quickly and grouping several changes together in a single release. Both goals are meant to ease overall downstream burden, but in different ways. Since we can't predict the future, it just comes down to an ongoing series of judgement calls.
Paraguay's change came to us at the height of the traditional "silly season". As is typical of said season when one particular change isn't immediately urgent, there were good reasons to wait at the time; namely, Brazil and Ukraine were simultaneously mulling changes that would have taken effect at similar or earlier times. They have since opted not to make those changes, so the balance has now shifted back toward cutting a release sooner.
But there are still some smaller things pending: We haven't heard anything more about the proposed legislation in the Philippines since August; since it could have effects from 1 January, it may make sense to wait a few more days to see whether that re-materializes or not. A new IERS Bulletin C (expected not to introduce a leap second in June 2025) will also arrive in early January; all else equal, including that could buy a new release extra validity time ahead of likely DST discussions in the US early next year.
And, of course, while I can't speak for Paul's personal schedule, one must remain mindful of folks' time as we enter the festive season: Releases invite more bug reports from a wider audience which can sometimes require another release on a quick turnaround. (You can help here by testing in advance!)
These kinds of highly fluid reasons are why we don't commit to timelines for any specific release. But hopefully illustrating them (non-exhaustively) above demonstrates that our target is indeed "not much longer" and will help assuage concerns.
-- Tim Parenti

On 1/13/25 13:12, Carlos Raúl Perasso wrote:
Is it possible to include Paraguay's change in the next release?
Yes, we're planning a release soon, and it'll have the Paraguay change. As far as I know, the only remaining item needing attention before a release is the MSVC issue mentioned on the mailing list today.

Thanks Paul! On Mon, Jan 13, 2025 at 6:36 PM Paul Eggert <eggert@cs.ucla.edu> wrote:
On 1/13/25 13:12, Carlos Raúl Perasso wrote:
Is it possible to include Paraguay's change in the next release?
Yes, we're planning a release soon, and it'll have the Paraguay change. As far as I know, the only remaining item needing attention before a release is the MSVC issue mentioned on the mailing list today.
participants (10)
-
brian.inglis@systematicsw.ab.ca
-
Carlos Raúl Perasso
-
Doug Ewell
-
Florian Weimer
-
Heitor David Pinto
-
ofrias@trabber.com
-
Paul Eggert
-
Tim Parenti
-
tzdb@time.is
-
Óscar Frías