Zefram wrote:
J. Shirley wrote:
Do not try to use named time zones (like America/Chicago) with dates
very far in the future (thousands of years). The current
implementation ofDateTime::TimeZone?will use a huge amount of memory
calculating all the DST changes from now until the future date.
Michael G Schwern wrote:
That looks like a great place to start. If it matches the DT::TZ
interface, and shipped a default time zone database, could DT::TZ simply
be replaced with it?
Almost. In principle, the DT:TZ way of working handles far future dates
slightly better.
DT:TZ:Tzfile can
2009/12/14 Kevin McGrath kmcgr...@baknet.com
The time_zone function in DateTime::Format::Strptime is only called with
parse_datetime. I think a nice feature would be to also set the time_zone
when calling format_datetime.
Keep in mind that DateTime::Format is a framework, and consistency
On Thu, 17 Dec 2009, Zefram wrote:
Almost. In principle, the DT:TZ way of working handles far future dates
slightly better.
I'd actually say this doesn't matter. Look at how often time zone
definitions change. Looking at America/Chicago, I see changes in 1974,
1975, 1976, 1987, and 2007.
Dave Rolsky wrote:
I don't think you need auto-downloads. People download a new DT::TZ when
I release one, or they don't. No one's complained about that.
It'll only rarely bite people. That doesn't make it OK. But that's an
orthogonal discussion that I don't want to stray into here.
The real
