I don't know why the JDK is doing what it is doing, but the rules do clearly stop in 2037. Since Joda-Time follows the rules, that is what you get. Stephen
I am clear on the functionality now, and the fact that it was intended. For me personally now, I would split this into two issues - First, there are different ways to interpret the tzdata. I can raise a bug on Oracle's bug site about this behavior but I am fully expecting an answer saying this is the way it is rather than getting a scientific reason. Second, just because tzdata is used by JDK, Joda and ICU among others doesn't make it infallible, the tzdata itself has shortcomings the most glaring being that in this case it is only till 2037. The author of the Iran data has clearly pointed out that he stops here because of the Unix Millennium bug (the http://en.wikipedia.org/wiki/Year_2038_problem) and the fact that he used Emacs to figure out the start of the Persian calendar year and the end of the sixth month of the same. I do not have that constraint and can generate the tzdata for this zone further that 2037 for myself and recompile Joda. I now have two options - 1. Append two rules for this zone with the FROM year being 2038 and TO year being 'max' just to match the JDK. 2. Generate real DST transitions using a more accurate Persian calendar formula than the Birask one used in tzdata for further (say a 100) years. Where it diverges from the JDK can be pointed out as a bug in Java. That Java does not have the correct date for DST transitions 2038 onwards (I verified) is a fact and not open to interpretation --- Nils Kilden-Pedersen - Out of interest and curiosity, can you elaborate on how DST plays a role in your financial system? I'm asking, because I've never encountered that before. DST does not play a role; but the difference in the two (JDK and Jods) does, in the following ways 1. Each framework (java.util and Joda) returns a different date for the same business function (like adding a certain period to a date, in this test case add days to date, I get junit.framework.AssertionFailedError: expected:<2038-03-22T00:00:00.000+05:30> but was:<2038-03-21T23:00:00.000+05:30>) Business functions like Treasury and Loans and Standing Instructions have to generate schedule based transactions to be executed at future dates. When passing the time between date objects or the two frameworks a difference MAY create a problem. I don't know. But I'd rather deal with it before hand. 2. Also the failed test case is hard to explain to others, (and myself). Ultimately, why the difference between Joda and JDK for future date calculations? At least, we should clarify this on the FAQ page. > > Nils Kilden-Pedersen - Considering the fact that DST is a political > function of time, I would be > hesitant to attach too much confidence in any future DST, particularly > the > more you go into the future. > > Hi Nils, I agree with you. The question is, based on what we know of the > rules today, do we keep applying them into the future for years where > we have no data? Going through the source and looking at that comment in > DateTimeZoneBuilder class I wasn't sure. A tailzone does not > necessarily mean max int year. > > Stephen Colebourne - The tzdata defines what Joda-Time should do. If the > data says that the rule > contines, then so should the Joda-Time interpretation. > I haven't looked at this specific case to say what it should do. Can you > paste the rules here? > Stephen > > Thanks Stephen, you answer clarifies the intent of the > DateTimeZoneBuilder code. > The driver of the question is that the JDKs and Joda dont agree with each > other - all the JDKs I tested all continue applying the rule > past 2037. That is only 25 years away, and considering I am deploying > Joda in an enterprise financial system which uses both Java and Joda > date functions, this is an annoying anomaly to say the least. > Agreed that this is my problem and not Joda-times (I may have to maintain > my own version of tzdata with a max added to the Iran rules) > but also, which functionality will apply after JSR310 comes to Java? > There may be some migration impact on persisted data already > generated by systems, however small, when users switch to Java 8? > > The Iran rules are below as requested - > > # From Roozbeh Pournader (2007-11-05): > # This is quoted from Official Gazette of the Islamic Republic of > # Iran, Volume 63, Number 18242, dated Tuesday 1386/6/24 > # [2007-10-16]. I am doing the best translation I can:... > # The official time of the country will be moved forward for one hour > # on the 24 hours of the first day of the month of Farvardin and will > # be changed back to its previous state on the 24 hours of the > # thirtieth day of Shahrivar. > # > # Rule NAME FROM TO TYPE IN ON AT SAVE > LETTER/S > Rule Iran 1978 1980 - Mar 21 0:00 1:00 D > Rule Iran 1978 only - Oct 21 0:00 0 S > Rule Iran 1979 only - Sep 19 0:00 0 S > Rule Iran 1980 only - Sep 23 0:00 0 S > Rule Iran 1991 only - May 3 0:00 1:00 D > Rule Iran 1992 1995 - Mar 22 0:00 1:00 D > Rule Iran 1991 1995 - Sep 22 0:00 0 S > Rule Iran 1996 only - Mar 21 0:00 1:00 D > Rule Iran 1996 only - Sep 21 0:00 0 S > Rule Iran 1997 1999 - Mar 22 0:00 1:00 D > Rule Iran 1997 1999 - Sep 22 0:00 0 S > Rule Iran 2000 only - Mar 21 0:00 1:00 D > Rule Iran 2000 only - Sep 21 0:00 0 S > Rule Iran 2001 2003 - Mar 22 0:00 1:00 D > Rule Iran 2001 2003 - Sep 22 0:00 0 S > Rule Iran 2004 only - Mar 21 0:00 1:00 D > Rule Iran 2004 only - Sep 21 0:00 0 S > Rule Iran 2005 only - Mar 22 0:00 1:00 D > Rule Iran 2005 only - Sep 22 0:00 0 S > Rule Iran 2008 only - Mar 21 0:00 1:00 D > Rule Iran 2008 only - Sep 21 0:00 0 S > Rule Iran 2009 2011 - Mar 22 0:00 1:00 D > Rule Iran 2009 2011 - Sep 22 0:00 0 S > Rule Iran 2012 only - Mar 21 0:00 1:00 D > Rule Iran 2012 only - Sep 21 0:00 0 S > Rule Iran 2013 2015 - Mar 22 0:00 1:00 D > Rule Iran 2013 2015 - Sep 22 0:00 0 S > Rule Iran 2016 only - Mar 21 0:00 1:00 D > Rule Iran 2016 only - Sep 21 0:00 0 S > Rule Iran 2017 2019 - Mar 22 0:00 1:00 D > Rule Iran 2017 2019 - Sep 22 0:00 0 S > Rule Iran 2020 only - Mar 21 0:00 1:00 D > Rule Iran 2020 only - Sep 21 0:00 0 S > Rule Iran 2021 2023 - Mar 22 0:00 1:00 D > Rule Iran 2021 2023 - Sep 22 0:00 0 S > Rule Iran 2024 only - Mar 21 0:00 1:00 D > Rule Iran 2024 only - Sep 21 0:00 0 S > Rule Iran 2025 2027 - Mar 22 0:00 1:00 D > Rule Iran 2025 2027 - Sep 22 0:00 0 S > Rule Iran 2028 2029 - Mar 21 0:00 1:00 D > Rule Iran 2028 2029 - Sep 21 0:00 0 S > Rule Iran 2030 2031 - Mar 22 0:00 1:00 D > Rule Iran 2030 2031 - Sep 22 0:00 0 S > Rule Iran 2032 2033 - Mar 21 0:00 1:00 D > Rule Iran 2032 2033 - Sep 21 0:00 0 S > Rule Iran 2034 2035 - Mar 22 0:00 1:00 D > Rule Iran 2034 2035 - Sep 22 0:00 0 S > Rule Iran 2036 2037 - Mar 21 0:00 1:00 D > Rule Iran 2036 2037 - Sep 21 0:00 0 S > # Zone NAME GMTOFF RULES FORMAT [UNTIL] > Zone Asia/Tehran 3:25:44 - LMT 1916 > 3:25:44 - TMT 1946 # Tehran Mean Time > 3:30 - IRST 1977 Nov > 4:00 Iran IR%sT 1979 > 3:30 Iran IR%sT > >> ** >> For a certain timezone (Tehran), DST transitions do not continue past >> the >> year 2037, which is the last year in the tzdata for which this zone has >> DST >> information. Are DST transitions supposed to continue as a simple rule >> following the last year rule, or stop completely if there is no data? >> >> I noticed the following - >> >> 1. Where tzdata has DST rules like 1996 to max (EU), the DST >> continues >> indefinitely (or at least to 100 years after compiling) >> 2. A comment in the class "org.joda.time.tz.DateTimeZoneBuilder", >> method "toDateTimeZone(String id, boolean outputID)" reads "// Tail >> zone >> picks up remaining transitions in the form of an endless DST cycle." >> The >> tailzone for the kind of zone without max given results in null (due >> to max >> not being specified in the tzdata) >> 3. A tailzone is built in the method "public DSTZone >> buildTailZone(String id)" in the class >> "org.joda.time.tz.DateTimeZoneBuilder", but it will only do so if the >> rules >> start year and end year are equal to max int value, else it returns >> null >> 4. JDKs (JRockit, HotSpot and IBM J9) seem to apply the last rule in >> 2037 further onwards for subsequent years >> >> To summarize - I am not sure if (not) applying DST transitions past the >> last year specified in tzdata, where max is not given, is a bug or a >> design >> decision? >> ____________________________________________________________ FREE 3D MARINE AQUARIUM SCREENSAVER - Watch dolphins, sharks & orcas on your desktop! Check it out at http://www.inbox.com/marineaquarium ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Joda-interest mailing list Joda-interest@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/joda-interest
