[threeten-dev] 64bit tzdata?

[yoshito_umaoka at us.ibm.com]

Okutsu-san,

Thank you for explaining some background.

> > As far as I know, current Java releases use 32bit tzdata (effective
> > between 1901-12-13T20:45:52Z and 2038-01-19T03:14:07Z)
> 
> JDK uses SimpleTimeZone for DST rules with "max" beyond 2038. It doesn't 

> have problems with future dates except for the limitations coming from 
> the SimpleTimeZone API.
> 
> >   and offsets

Right. I agree that it's not a major concern at this point.

> > returned by java.util.TimeZone for dates before 1900 does not match 
the tz
> > database in many cases.
> 
> There were some customer codes which assumed consistent GMT offsets for 
> old dates. In other words, apps assumed the SimpleTimeZone-based time 
> zone support. I didn't want to break those apps back in 2000, which is 
> the reason why JDK didn't introduce support for LMT.

I guessed this was the intent.
However, it also introduced artificial transition at 1900-01-01T00:00Z 
(not local time) that is a little bit difficult to understand.
Also, I suspect offset before 1900 was hardcoded somewhere and it's not 
necessarily matches the current GMT raw offset. (For example, Asia/Dili 
before 1900 returns +8 hours, while the zone uses +9 hours since Sep 
2000...)

Anyway, I just want to clarify if this hack will be gone with the new 
JSR-310 implementation.

Thanks,
Yoshito