Bug #114064 for DateTime: Allow default timezone other than "floating"

Fri Apr 29 05:29:29 2016 ovid [...] cpan.org - Ticket created

Subject:

Allow default timezone other than "floating"

My client would desperately love official DateTime support for a default time zone. The following shows my problem: $ perl -MDateTime -E 'say DateTime->new( year => 2016, month => 4, day => 23 )->time_zone->name' floating $ perl -MDateTime -E 'say DateTime->now->time_zone->name' UTC I have a US-based client with a very large I18N project and for years they've ignored the time zone on DateTime objects, thus causing their code to be a mixture of "floating" and "UTC" time zones. Sometimes they remember to set their time zone to America/Los_Angeles, but not always. Worse, some external tools such as DateTime::Format::MySQL assume the floating time zone, but others such as DateTime::Format::SQLite assume UTC, which means virtually identical software stacks can have significantly different behavior. We cannot (yet) migrate all of our dates to UTC, so for the time being, I've written a DBIx::Class inflator which forces the LA time zone. However, I can't control all of the places where DateTime objects are generated in our code. Further, because so much of the Perl ecosystem assumes DateTime objects and won't allow us to easily generate a subclass of DateTime, even that route has proved to be unworkable. Having a config file or an environment variable which allows us to set different defaults to DateTime would be very helpful. Our current approach is monkey-patching or worse, maintaining an internal DateTime fork. Best, Ovid

Fri May 06 23:38:13 2016 DROLSKY [...] cpan.org - Correspondence added

On Fri Apr 29 05:29:29 2016, OVID wrote: Show quoted text

> My client would desperately love official DateTime support for a > default time zone. > > The following shows my problem: > > $ perl -MDateTime -E 'say DateTime->new( year => 2016, month => 4, day > => 23 )->time_zone->name' > floating > $ > perl -MDateTime -E 'say DateTime->now->time_zone->name' > UTC > > I have a US-based client with a very large I18N project and for years > they've ignored the time zone on DateTime objects, thus causing their > code to be a mixture of "floating" and "UTC" time zones. Sometimes > they remember to set their time zone to America/Los_Angeles, but not > always. Worse, some external tools such as DateTime::Format::MySQL > assume the floating time zone, but others such as > DateTime::Format::SQLite assume UTC, which means virtually identical > software stacks can have significantly different behavior. > > We cannot (yet) migrate all of our dates to UTC, so for the time > being, I've written a DBIx::Class inflator which forces the LA time > zone. However, I can't control all of the places where DateTime > objects are generated in our code. Further, because so much of the > Perl ecosystem assumes DateTime objects and won't allow us to easily > generate a subclass of DateTime, even that route has proved to be > unworkable. > > Having a config file or an environment variable which allows us to set > different defaults to DateTime would be very helpful. Our current > approach is monkey-patching or worse, maintaining an internal DateTime > fork.

I've resisted this in the past, but you do make a compelling case for it. I'd accept a PR to add an environment variable for this. I'll add the accompanying docs explaining why it's incredibly dangerous to use ;)

Fri May 06 23:38:13 2016 The RT System itself - Status changed from 'new' to 'open'

Mon May 09 04:59:22 2016 ovid [...] cpan.org - Correspondence added

Thank you. I've submitted the PR as https://github.com/autarch/DateTime.pm/pull/14 On Fri May 06 23:38:13 2016, DROLSKY wrote: Show quoted text

> On Fri Apr 29 05:29:29 2016, OVID wrote:

> > My client would desperately love official DateTime support for a > > default time zone. > > > > The following shows my problem: > > > > $ perl -MDateTime -E 'say DateTime->new( year => 2016, month => 4, > > day > > => 23 )->time_zone->name' > > floating > > $ > > perl -MDateTime -E 'say DateTime->now->time_zone->name' > > UTC > > > > I have a US-based client with a very large I18N project and for years > > they've ignored the time zone on DateTime objects, thus causing their > > code to be a mixture of "floating" and "UTC" time zones. Sometimes > > they remember to set their time zone to America/Los_Angeles, but not > > always. Worse, some external tools such as DateTime::Format::MySQL > > assume the floating time zone, but others such as > > DateTime::Format::SQLite assume UTC, which means virtually identical > > software stacks can have significantly different behavior. > > > > We cannot (yet) migrate all of our dates to UTC, so for the time > > being, I've written a DBIx::Class inflator which forces the LA time > > zone. However, I can't control all of the places where DateTime > > objects are generated in our code. Further, because so much of the > > Perl ecosystem assumes DateTime objects and won't allow us to easily > > generate a subclass of DateTime, even that route has proved to be > > unworkable. > > > > Having a config file or an environment variable which allows us to > > set > > different defaults to DateTime would be very helpful. Our current > > approach is monkey-patching or worse, maintaining an internal > > DateTime > > fork.

> > I've resisted this in the past, but you do make a compelling case for > it. I'd accept a PR to add an environment variable for this. I'll add > the accompanying docs explaining why it's incredibly dangerous to use > ;)

Fri May 13 19:51:49 2016 DROLSKY [...] cpan.org - Status changed from 'open' to 'resolved'

Fri May 13 19:51:50 2016 DROLSKY [...] cpan.org - Broken in 1.27 added

Bug #114064 for DateTime: Allow default timezone other than "floating"

Preferred bug tracker