FW: timelocal() discrepancy vs DateTime->epoch

2017-03-15 Thread Lu Feng
I noticed that the UNIX time from timelocal() started to differ from that
you get from using DateTime module, for dates earlier than 11/6/1910.
 
For the America/New_York local timezone, timelocal() thinks there was a DST
switch on 11/6/1910, while DateTime module thinks there was none.
 
If you run the attached script (after setting your host TZ env to New York)
twice (with Perl 5.24), you will see these outputs:
 
F:\ABT\Dev\PerlUtil>perl David.pl 1910 11 06 08 00 00
Epoch for 19101106:08 (UTC) =   -1866729600 based on Epoch().
Epoch for 19101106:08 (UTC) =   -1866729600 based on timegm().
Epoch for 19101106:08 (NYC) =   -1866711600 based on Epoch().
Epoch for 19101106:08 (NYC) =   -1866711600 based on
timelocal().
 
F:\ABT\Dev\PerlUtil>perl David.pl 1910 11 05 08 00 00
Epoch for 19101105:08 (UTC) =   -1866816000 based on Epoch().
Epoch for 19101105:08 (UTC) =   -1866816000 based on timegm().
Epoch for 19101105:08 (NYC) =   -1866798000 based on Epoch().
Epoch for 19101105:08 (NYC) =   -1866801600 based on
timelocal().
 
So it seems either DateTime or timelocal() has a bug regarding the DST
switch over on 11/6/1910.  Am I missing something?
 
Regards,
Lu Feng


David.pl
Description: Binary data


small DateTime optimization

2017-03-15 Thread Flavio S. Glock
We've been using this patch at work for years, and I just forgot to
contribute it back. I hope you find it worth applying.

I believe the typical use case was:

  my $dt = $param || DateTime->now();

In this case $param is used in boolean context, which makes a fallback call
to _stringify(). With the patch, "boolean" just returns true.

The stringification change is a micro-optimization, it is not that
important.



# optimize boolean and string
use overload
'""'  => sub {
   $_[0]->ymd('-') . 'T' . $_[0]->hms(':')
 },
bool  => sub { 1 },

'<=>' => '_compare_overload',
'cmp' => '_compare_overload',
'-'   => '_subtract_overload',
'+'   => '_add_overload',
fallback   => 1;