Carnival Sunday in Brazil

According to Federico A. C. Neves and Herton Ronaldo Krzesinski there are some exceptions to the rule of ending DST Third Sunday of February in Brazil, which seems to be correct. I just wanted to point out that there is a Carnival dates calculator at HYPERLINK "http://www.ipanema.com/carnival/dates.htm"http://www.ipanema.com/carnival/d ates.htm from which I calculated the following Carnival Sunday list for 2008 to 2041: Carnival Sunday 2008-2041: 2008-02-03 2009-02-22 2010-02-14 2011-03-06 2012-02-19 2013-02-10 2014-03-02 2015-02-15 2016-02-07 2017-02-26 2018-02-11 2019-03-03 2020-02-23 2021-02-14 2022-02-27 2023-02-19 2024-02-11 2025-03-02 2026-02-15 2027-02-07 2028-02-27 2029-02-11 2030-03-03 2031-02-23 2032-02-08 2033-02-27 2034-02-19 2035-02-04 2036-02-24 2037-02-15 2038-03-07 2039-02-20 2040-02-12 2041-03-03 This basically confirms the rules elaborated. Note that there is a typo "bellow" in the rules given in the earlier email, and that perhaps instead of giving specific dates, it might be better to give the rule for the exception dates like this: +Rule Brazil 2008 2011 - Feb Sun>=15 0:00 0 - +Rule Brazil 2012 only - Feb Sun>=22 0:00 0 - +Rule Brazil 2013 2014 - Feb Sun>=15 0:00 0 - +Rule Brazil 2015 only - Feb Sun>=22 0:00 0 - +Rule Brazil 2016 2022 - Feb Sun>=15 0:00 0 - +Rule Brazil 2023 only - Feb Sun>=22 0:00 0 - +Rule Brazil 2024 2025 - Feb Sun>=15 0:00 0 - +Rule Brazil 2026 only - Feb Sun>=22 0:00 0 - +Rule Brazil 2027 2033 - Feb Sun>=15 0:00 0 - +Rule Brazil 2034 only - Feb Sun>=22 0:00 0 - +Rule Brazil 2035 2036 - Feb Sun>=15 0:00 0 - +Rule Brazil 2037 only - Feb Sun>=22 0:00 0 - +Rule Brazil 2038 max - Feb Sun>=15 0:00 0 - This should give the same actual dates, but will give a hint on how the dates behave after 2038. A bit a matter of taste I admit. Usually we don't give rules as Sun>=x when this spans only one year, but here the same rule Sun>=22 is applied a few years later each cycle. - Jesper Nørgaard Welen No virus found in this outgoing message. Checked by AVG. Version: 7.5.524 / Virus Database: 270.7.0/1681 - Release Date: 2008-09-19 15:54

Jesper's... Rule Brazil 2012 only - Feb Sun>=22 0:00 0 - ...does seem preferable to using the actual dates; as Jesper notes, it "will give a hint on how the dates behave after 2038." Another possibility is to express the rules as... Rule Brazil 2008 max earlycarnival Feb Sun>=15 0:00 0 - Rule Brazil 2008 max latecarnival Feb Sun>=22 0:00 0 - ...with suitable additions to the "yearistype" script--including, but not limited to, 2-earlycarnival|2-latecarnival) case $1 in 2012|2015|2023|2026|2034|2037) late=1 ;; *) late=0 ;; esac case $2-$late in earlycarnival-0|latecarnival-1) exit 0 ;; *) exit 1 ;; esac ;; Yet another possibility is to cobble up a Carnival calculating executable that can be used by yearistype (instead of hard-coding the years as above). Both this approach and the hard-coded approach merit caution: the yearistype mechanism hasn't been used for real-world stuff in some years. Long term, given the non-repeating nature of Carnival (it's not on a 400-year cycle since it depends on the phase of the moon) it might be best to incorporate the Carnival calculator into localtime; that's a non-trivial endeavor. For purposes of getting something correct and safe out the door now, I'd go with Jesper's approach. --ado

On Mon, 22 Sep 2008, Olson, Arthur David (NIH/NCI) [E] wrote:
Another possibility is to express the rules as... Rule Brazil 2008 max earlycarnival Feb Sun>=15 0:00 0 - Rule Brazil 2008 max latecarnival Feb Sun>=22 0:00 0 - ...with suitable additions to the "yearistype" script--including, but not limited to, 2-earlycarnival|2-latecarnival) case $1 in 2012|2015|2023|2026|2034|2037) late=1 ;; *) late=0 ;; esac case $2-$late in earlycarnival-0|latecarnival-1) exit 0 ;; *) exit 1 ;; esac ;;
Arg, please don't! Those of us who write our own parsers will thank you for not changing the format with weird little special cases ;)
Yet another possibility is to cobble up a Carnival calculating executable that can be used by yearistype (instead of hard-coding the years as above). Both this approach and the hard-coded approach merit caution: the yearistype mechanism hasn't been used for real-world stuff in some years.
This is even worse for those of us with our own parsers. I really would like to see the tz file format remain something self-contained. Ideally, it'd be documented outside of the C code that parses it. Even more ideally, it'd remain as simple as possible. -dave /*========================== VegGuide.Org Your guide to all that's veg ==========================*/

Date: Mon, 22 Sep 2008 10:18:57 -0500 (CDT) From: Dave Rolsky <autarch@urth.org> Message-ID: <alpine.DEB.0.9999.0809221016420.31443@urth.org> | Those of us who write our own parsers will thank you for not changing the | format with weird little special cases ;) That wouldn't be changing the format. If you're parsing the tz format files (the text input, rather than the zic output) and you're not handling the exception scripts, then you're not parsing the tz format, just a rough approximation. This stuff isn't new, it has been there forever, and was once actively used (though as Arthur said, not for a while now...) That isn't to say that I think it is a good idea to do it this way. A script to figure out Brazillian carnival dates (which from what I saw just means figure out Easter, and subtract) might be useful for other purposes, but using it here isn't really warranted I suspect. Even less would be embedding code into localtime for this (that is, extending the compiled zoneinfo file format to add some extra magic). Recall, we're dealing with Summer time dates here - one of those things that the world's governments fiddle with for almost undetectable reasons, planning something with an expectation that it might be useful for hundreds of years seems a little over optimistic. Just stick in the dates that are calculated now, it sees to me that the chances that the rules will remain the same up to 2030 or something are close to zero anyway - that is, by the time we'd need to be doing more, we probably won't be doing the same thing anyway. kre

On Tue, 23 Sep 2008, Robert Elz wrote:
That wouldn't be changing the format. If you're parsing the tz format files (the text input, rather than the zic output) and you're not handling the exception scripts, then you're not parsing the tz format, just a rough approximation. This stuff isn't new, it has been there forever, and was once actively used (though as Arthur said, not for a while now...)
Well, it hasn't been used for quite some time. I've been maintaining the Perl DateTime::TimeZone library for about 5 years now, and I never knew about these scripts, of which there is exactly one, which is not used. Apparently my "rough approximation" was pretty accurate, given I generate comprehensive tests for every zone in the database based on the output of zdump, and all the tests have been passing with every release for quite some time. My hope is that these scripts are never used, since parsing the time zone data is hard enough already, which was my original point. A "file format" that also includes "and for this case run some random shell script" is a bit out there. At the very least, it'd be nice to see any instances of such things documented as _algorithms_ so that they can be reimplemented for other cases. For example, with my library, I handle dates past 2038, though with cases like Iran, it just uses the last rule it knows about, which is clearly wrong. -dave /*========================== VegGuide.Org Your guide to all that's veg ==========================*/
participants (4)
-
Dave Rolsky
-
Jesper Norgaard Welen
-
Olson, Arthur David (NIH/NCI) [E]
-
Robert Elz