or would that be considered illegal? Why is the time zone itself not sufficient to clarify the timestamp?
Brian FrankTue 9 Oct 2012
GMT +/- named offsets are reverse of their actual UTC offset, I don't personally get it either, but just use what Olson database has.
But essentially the Java implementation is a bit of a hack to deal with the fact that we don't have a complete database we can trust for all the offsets (if working on J2ME platforms). So I pass around offset and timezone together even though they are sort of duplicate information
Matthew Giannini Tue 9 Oct 2012
I'm a little confused about the purpose of the tzOffset in HDateTime. Is it supposed to correspond to the HTimeZone used in the HDateTime?
For example, in the test suite there is this code
verifyZinc(HDateTime.make(2011, 6, 7, 11, 3, 43, HTimeZone.make("GMT+10"), -36000), "2011-06-07T11:03:43-10:00 GMT+10");I'm not sure why you would specify a time zone of GMT+10, but then give an offset of (if I understand correctly) essentially GMT-10.
Would it be valid to construct a HDateTime as
make(y,m,d,h,m,s, HTimeZone.make("New_York"), -36000)or would that be considered illegal? Why is the time zone itself not sufficient to clarify the timestamp?
Brian Frank Tue 9 Oct 2012
GMT +/- named offsets are reverse of their actual UTC offset, I don't personally get it either, but just use what Olson database has.
But essentially the Java implementation is a bit of a hack to deal with the fact that we don't have a complete database we can trust for all the offsets (if working on J2ME platforms). So I pass around offset and timezone together even though they are sort of duplicate information