Thomas Klausner wrote: >I though a lot about how this could be done. The problem here of course >is that DateTime::TimeZone->new is called in various places in DateTime >(and potentially other code), so this new parameter would need to be handled >by DateTime AND DateTime::TimeZone:
DT:TZ classes would have to support the functionality for it to work, but not for the reason you give. You're treating this behaviour as an inherent aspect of a timezone: > time_zone=>'America/Sao_Paulo:FIX', # ugly! ... > time_zone=>['America/Sao_Paulo' => 'fix_invalid_local_time' ], ... >Both of those ideas only have to be implemented in one place: >DateTime::TimeZone->new This is the wrong way round. The timezone you want is the same America/Sao_Paulo either way; you're just *doing something different with it*. The support you need for find-next-valid-local-datetime should be a new *method* in the DT:TZ API. DateTime->new, if asked (by flag parameter) to perform find-next-valid-local-time rather than to represent a time exactly, would apply logic that involves calling the new method on whatever timezone object was selected. The new method doesn't need to be available in all DT:TZ classes at once. (This is important because it won't be available in all: anyone can implement a compatible timezone object class to the current API.) When the new functionality is required, you only need the new method to exist on the timezone object that you're actually using. Availability can be detected with ->can, so you can get a clean error message when trying to use it with a timezone class that doesn't support it. -zefram
