Matt Sisk wrote: > > My understanding with the current behavior is that if you set the > time_zone for the set, that time zone will override the time zone of a > datetime argument.
Besides, the time zone is being applied in the wrong order. This should be fixed. The current implementation only works properly when: - the argument to next() is a floating time zone, or - there is no backtracking involved (the set is not infinite) > (since, as was previously discussed, it is > actually a factory method rather than a mutator) But this is not the reason why it doesn't work. There is no code in place to do the proper backtracking of the set_time_zone operation. And this is actually a bit complex to write. > Instead, just rely on > setting the time zone of the original datetime. I agree. As for the factory vs. mutator, would anyone give a final word on whether this should be changed? The following DateTime::Set methods could be mutators: set_time_zone set( locale => ... ) add_duration add( years => ... ) subtract_duration subtract( years => ... ) - Flavio S. Glock
