EsTimeZoneRuleSet>>#offset uses the following expression. But because #localOffsetSecondsAt: does not handle EsPointInTime instances (despite what's advertised), it works by coincidence.
self localOffsetSecondsAt: EsPointInTime now
If a future president were to decide that another Daylight Savings Time adjustment were called for, the #offset method would select the new time zone rule as soon as it was published, not just once it comes into effect. The problem is that #localOffsetSecondsAt: (and related methods) compare the argument to integers from the Olson TZ database, but EsPointInTime instances are NOT comparable to Integer or anything else.
If one were to call #localOffsetSecondsAt: with an EsPointInTime from 1970 or so, it would still answer the most recent time zone rule.
On Friday, January 31, 2014 5:14:36 PM UTC-8, Donald MacQueen wrote:
Richard,
I am not sure what you are saying here, so how about a use case that shows the problem?
Thanks,
Donald [|]
On Friday, January 31, 2014 5:35:13 PM UTC-5, Richard Sargent wrote:
EsTimeZoneRuleSet>>#offset relies on the fact that EsPointInTime comparisons to the time zone rule set transition seconds don't work. EsPointInTime will only compare against another EsPointInTime. The attempt to compare against the seconds in the transition tables always give the wrong answer, fortuitously selecting the highest numbered rule.
The same error exists in 8.6 as well.
The consequence of this is that #localOffsetSecondsAt: cannot be used with an EsPointInTime argument.
--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
[hidden email].
To post to this group, send email to
[hidden email].
Visit this group at
http://groups.google.com/group/va-smalltalk.
For more options, visit
https://groups.google.com/groups/opt_out.
Locked
