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
On 6 September 2012 14:31, Zubin Kavarana <zubinkavar...@inbox.com> wrote: > 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 Online Photosharing - Share your photos online with your friends and > family! > Visit http://www.inbox.com/photosharing to find out more! > > ------------------------------------------------------------------------------ > 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 > ------------------------------------------------------------------------------ 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
