On 10/01/2012 12:04 PM, Zefram wrote: > Mark Stosberg wrote: >> It seems like a useful alternate design might be add this class method: >> >> DateTime->DefaultTimeZone($tz); > > That would make the "default timezone" a global variable. If two modules > in one program both attempt to set it, you lose. If a module sets it > and the main program also does, you lose. So to be safe, you can never > set this in a reusable module. > > It gets worse. You're proposing to have this global variable used in > places that currently use a constant. Effectively, lots of code that > currently works fine by relying on the constant would now be reading the > new variable. So if your main program sets the variable to any other > value, and you're using any of the modules already on CPAN that rely on > the current behaviour, you lose.
Thanks for that feedback. You made a good case against this approach. > Which timezone a particular DateTime object needs is not so much a > function of the application it's in, but of the way it's used in its > immediate surroundings. There are three main cases, corresponding > to the timezone designators "UTC" (for an absolute point in time), > "floating" (for a calendar time in no particular zone), and "local" > (for describing a point in time to users). A few applications need to > use multiple local timezones, due to people crossing localities. > > Each piece of code that generates DateTime objects should know the > broad purpose of those objects, and hence which kind of timezone they > should use. They should generally set the timezone slot explicitly. > Relying on the "floating" default is acceptable, but being explicit > about it is better. So, it sounds like being explicit is the way to go. The DateTimeX::Local approach would be explicit, while adding another layer of abstraction. It would be: DateTimeX::Local->new; vs: DateTime->new( time_zone => 'local' ); For a project that does a lot of object creation, I the shorthand could still be nice. Mark
