Do DST transtitions continue after the last year specified in tzdata rules?

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Do DST transtitions continue after the last year specified in tzdata rules?

Zubin Kavarana
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?



Try IM ToolPack Send your photos by email in seconds...
Try FREE IM ToolPack at www.imtoolpack.com
Works in all emails, instant messengers, blogs, forums and social networks.

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/joda-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Do DST transtitions continue after the last year specified in tzdata rules?

jodastephen
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

On 6 September 2012 11:36, Zubin Kavarana <[hidden email]> wrote:
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?



Try IM ToolPack Send your photos by email in seconds...
Try FREE IM ToolPack at www.imtoolpack.com
Works in all emails, instant messengers, blogs, forums and social networks.

------------------------------------------------------------------------------
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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/joda-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Do DST transtitions continue after the last year specified in tzdata rules?

Nils Kilden-Pedersen
In reply to this post by Zubin Kavarana
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.

On Thu, Sep 6, 2012 at 5:36 AM, Zubin Kavarana <[hidden email]> wrote:
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?



Try IM ToolPack Send your photos by email in seconds...
Try FREE IM ToolPack at www.imtoolpack.com
Works in all emails, instant messengers, blogs, forums and social networks.

------------------------------------------------------------------------------
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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/joda-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Do DST transtitions continue after the last year specified in tzdata rules?

Zubin Kavarana
In reply to this post by Zubin Kavarana
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/joda-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Do DST transtitions continue after the last year specified in tzdata rules?

Nils Kilden-Pedersen
On Thu, Sep 6, 2012 at 8:31 AM, Zubin Kavarana <[hidden email]> wrote:
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
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.


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/joda-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Do DST transtitions continue after the last year specified in tzdata rules?

Zubin Kavarana
In reply to this post by Zubin Kavarana
If I could be so humble as to ask you to delete/ignore that previous mail with the HTML in
it?

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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/joda-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Do DST transtitions continue after the last year specified in tzdata rules?

jodastephen
In reply to this post by Zubin Kavarana
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 <[hidden email]> 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/joda-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Do DST transtitions continue after the last year specified in tzdata rules?

Zubin Kavarana
In reply to this post by Zubin Kavarana
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/joda-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Do DST transtitions continue after the last year specified in tzdata rules?

jodastephen
On 7 September 2012 10:26, Zubin Kavarana <[hidden email]> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/joda-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Do DST transtitions continue after the last year specified in tzdata rules?

Zubin Kavarana
In reply to this post by Zubin Kavarana
> 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.

I totally agree, IMHO this is a bug in the JDKs.

> 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.

At this point since the application uses both java.util.Calendar and Joda
I'd like them to give consistent results while I migrate from one
style to another, DST included.

The need to have DST information that far in the future is subjective.
Agreed that DST is volatile, but ultimately the same database gives
information till 'max' for some zones and till certain years for others
so it's got multiple standards. Why couldn't all zones be specified till
a certain year say 2100 if it's so volatile? This isn't a problem with
Joda or JDK/ICU4j, but the tzdata.
The author of the IRAN section has clearly documented his constraint
(integer overflow for dates after 2037) which is a constraint that doesn't
apply to everyone. What if he had used Java rather than EMACS and
generated DST till 3000 AD? We would have accepted it even if we feel
we do not need that much DST information.
I can send a mail to the IANA mailing list and contribute data for this timezone
further than 2037 :)

____________________________________________________________
GET FREE SMILEYS FOR YOUR IM & EMAIL - Learn more at http://www.inbox.com/smileys
Works with AIM®, MSN® Messenger, Yahoo!® Messenger, ICQ®, Google Talk™ and most webmails



------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/joda-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Do DST transititions continue after the last year specified in tzdata rules?

Roger Riggs
Hi,

Please file a bug, that will prompt a more detailed investigation.

Thanks, Roger

On 9/10/12 2:34 AM, Zubin Kavarana wrote:
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.
I totally agree, IMHO this is a bug in the JDKs.

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.
At this point since the application uses both java.util.Calendar and Joda
I'd like them to give consistent results while I migrate from one
style to another, DST included.

The need to have DST information that far in the future is subjective.
Agreed that DST is volatile, but ultimately the same database gives 
information till 'max' for some zones and till certain years for others
so it's got multiple standards. Why couldn't all zones be specified till 
a certain year say 2100 if it's so volatile? This isn't a problem with
Joda or JDK/ICU4j, but the tzdata.
The author of the IRAN section has clearly documented his constraint
(integer overflow for dates after 2037) which is a constraint that doesn't
apply to everyone. What if he had used Java rather than EMACS and 
generated DST till 3000 AD? We would have accepted it even if we feel 
we do not need that much DST information.
I can send a mail to the IANA mailing list and contribute data for this timezone
further than 2037 :)

____________________________________________________________
GET FREE SMILEYS FOR YOUR IM & EMAIL - Learn more at http://www.inbox.com/smileys
Works with AIM®, MSN® Messenger, Yahoo!® Messenger, ICQ®, Google Talk™ and most webmails



------------------------------------------------------------------------------
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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/joda-interest
Loading...