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. >What do you think about the best way to set the time zone to "local" >across a large project? 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. -zefram
