On 7 September 2012 10:26, Zubin Kavarana <zubinkavar...@inbox.com> wrote: > 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
Clearly the JDK is making stuff up by changing to max if the last date is 2038. That is dubious, as you've shown the DST dates diverge post 2038 from the real ones. In my opinion, you shouldn't need to have DST information that far in the future anyway. Its almost certain to change as governments change the rules over time. Perhaps your application should be representing the date using LocalDate rather than DateTime, that way the far future DST doesn't matter. In any case, any future DST transitions are always estimates. Stephen ------------------------------------------------------------------------------ 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
