Bug #102785 for DateTime: 1895-02-01 Australia/Melbourne - Invalid local time for date in time zone: Australia/Melbourne

Sun Mar 15 08:15:50 2015 brettrann [...] gmail.com - Ticket created

Subject:	1895-02-01 Australia/Melbourne - Invalid local time for date in time zone: Australia/Melbourne
Date:	Sun, 15 Mar 2015 23:15:30 +1100
To:	bug-DateTime [...] rt.cpan.org
From:	brett rann <brettrann [...] gmail.com>

Using DateTime-1.85: Show quoted text

> perl -e 'use DateTime; print new DateTime(year => 1895, month => 02, day

=> 01, time_zone => "Australia/Melbourne"), $/;' Show quoted text

> Invalid local time for date in time zone: Australia/Melbourne

It works with surrounding days, months, years. I note this code in: perl5/DateTime/TimeZone/Australia/Melbourne.pm 20 my $spans = 21 [ 22 [ 23 DateTime::TimeZone::NEG_INFINITY, # utc_start 24 59771571608, # utc_end 1895-01-31 14:20:08 (Thu) 25 DateTime::TimeZone::NEG_INFINITY, # local_start 26 59771606400, # local_end 1895-02-01 00:00:00 (Fri) 27 34792, 28 0, 29 'LMT', 30 ], 31 [ 32 59771571608, # utc_start 1895-01-31 14:20:08 (Thu) 33 60463116060, # utc_end 1916-12-31 14:01:00 (Sun) 34 59771607608, # local_start 1895-02-01 00:20:08 (Fri) 35 60463152060, # local_end 1917-01-01 00:01:00 (Mon) 36 36000, 37 0, 38 'AEST', 39 ], Something is possibly not right there.

Mon Mar 16 11:40:49 2015 DROLSKY [...] cpan.org - Correspondence added

On Sun Mar 15 08:15:50 2015, brettrann@gmail.com wrote: Show quoted text

> Using DateTime-1.85: >

> > perl -e 'use DateTime; print new DateTime(year => 1895, month => 02, day

> => 01, time_zone => "Australia/Melbourne"), $/;' >

> > Invalid local time for date in time zone: Australia/Melbourne

> > It works with surrounding days, months, years. > > I note this code in: > perl5/DateTime/TimeZone/Australia/Melbourne.pm > > 20 my $spans = > 21 [ > 22 [ > 23 DateTime::TimeZone::NEG_INFINITY, # utc_start > 24 59771571608, # utc_end 1895-01-31 14:20:08 (Thu) > 25 DateTime::TimeZone::NEG_INFINITY, # local_start > 26 59771606400, # local_end 1895-02-01 00:00:00 (Fri) > 27 34792, > 28 0, > 29 'LMT', > 30 ], > 31 [ > 32 59771571608, # utc_start 1895-01-31 14:20:08 (Thu) > 33 60463116060, # utc_end 1916-12-31 14:01:00 (Sun) > 34 59771607608, # local_start 1895-02-01 00:20:08 (Fri) > 35 60463152060, # local_end 1917-01-01 00:01:00 (Mon) > 36 36000, > 37 0, > 38 'AEST', > 39 ], > > Something is possibly not right there.

I'm not sure what you expected. Looking at the raw Olson data files, I see that Australia/Melbourne moved from an offset of +09:39.52 to +10:00.00 on February 1, 1895. That means that the clocks moved forward slightly more than 20 minutes, leaving a 20 minute gap in the local time that simply doesn't exist.

Mon Mar 16 11:40:50 2015 The RT System itself - Status changed from 'new' to 'open'

Mon Mar 16 16:00:44 2015 brettrann [...] gmail.com - Correspondence added

Subject:	Re: [rt.cpan.org #102785] 1895-02-01 Australia/Melbourne - Invalid local time for date in time zone: Australia/Melbourne
Date:	Tue, 17 Mar 2015 07:00:21 +1100
To:	"bug-DateTime [...] rt.cpan.org" <bug-DateTime [...] rt.cpan.org>
From:	Brett Rann <brettrann [...] gmail.com>

I expected to be able to get a date object representing that day, when time wasn't specified. Not the library dying acting as if that was too hard. If the beginning of that day needs to be 20:08 then so be it. Well. The programmer that used DateTime to format years did. Show quoted text

> On 17 Mar 2015, at 02:41, Dave Rolsky via RT <bug-DateTime@rt.cpan.org> wrote: > > <URL: https://rt.cpan.org/Ticket/Display.html?id=102785 > >

>> On Sun Mar 15 08:15:50 2015, brettrann@gmail.com wrote: >> Using DateTime-1.85: >>

>>> perl -e 'use DateTime; print new DateTime(year => 1895, month => 02, day

>> => 01, time_zone => "Australia/Melbourne"), $/;' >>

>>> Invalid local time for date in time zone: Australia/Melbourne

>> >> It works with surrounding days, months, years. >> >> I note this code in: >> perl5/DateTime/TimeZone/Australia/Melbourne.pm >> >> 20 my $spans = >> 21 [ >> 22 [ >> 23 DateTime::TimeZone::NEG_INFINITY, # utc_start >> 24 59771571608, # utc_end 1895-01-31 14:20:08 (Thu) >> 25 DateTime::TimeZone::NEG_INFINITY, # local_start >> 26 59771606400, # local_end 1895-02-01 00:00:00 (Fri) >> 27 34792, >> 28 0, >> 29 'LMT', >> 30 ], >> 31 [ >> 32 59771571608, # utc_start 1895-01-31 14:20:08 (Thu) >> 33 60463116060, # utc_end 1916-12-31 14:01:00 (Sun) >> 34 59771607608, # local_start 1895-02-01 00:20:08 (Fri) >> 35 60463152060, # local_end 1917-01-01 00:01:00 (Mon) >> 36 36000, >> 37 0, >> 38 'AEST', >> 39 ], >> >> Something is possibly not right there.

> > I'm not sure what you expected. Looking at the raw Olson data files, I see that Australia/Melbourne moved from an offset of +09:39.52 to +10:00.00 on February 1, 1895. That means that the clocks moved forward slightly more than 20 minutes, leaving a 20 minute gap in the local time that simply doesn't exist. >

Mon Mar 16 16:24:33 2015 DROLSKY [...] cpan.org - Correspondence added

On Mon Mar 16 16:00:44 2015, brettrann@gmail.com wrote: Show quoted text

> I expected to be able to get a date object representing that day, when > time wasn't specified. Not the library dying acting as if that was too > hard. If the beginning of that day needs to be 20:08 then so be it.

There's no need to be snarky. When I asked what you expected I really wanted to know what you thought was wrong. I missed that you didn't specify a time in the code sample you provided. The offset moved from +09:39.52 to +10:00.00 at midnight, so midnight on that day doesn't exist in the local time. You can verify this by running this command - "zdump -v Australia/Melbourne", which outputs the following: Australia/Melbourne Thu Jan 31 14:20:07 1895 UT = Thu Jan 31 23:59:59 1895 LMT isdst=0 gmtoff=34792 Australia/Melbourne Thu Jan 31 14:20:08 1895 UT = Fri Feb 1 00:20:08 1895 AEST isdst=0 gmtoff=36000 As you can see, it skips from 23:59:59 to 00:20:08. Time zones are weird. If you want to just represent dates and do date math without worrying about times, you should create all your dates using the floating time zone, which is a sort of "fake" zone that doesn't have any DST transitions.

Mon Mar 16 16:24:39 2015 DROLSKY [...] cpan.org - Status changed from 'open' to 'rejected'

Mon Mar 16 19:40:54 2015 brettrann [...] gmail.com - Correspondence added

Subject:	Re: [rt.cpan.org #102785] 1895-02-01 Australia/Melbourne - Invalid local time for date in time zone: Australia/Melbourne
Date:	Tue, 17 Mar 2015 10:40:43 +1100
To:	"bug-DateTime [...] rt.cpan.org" <bug-DateTime [...] rt.cpan.org>
From:	brett rann <brettrann [...] gmail.com>

Hi Dave, I really wasn't being snarky. Lost in translations perhaps. You asked what I expected, so I replied with what I expected the behavior to be. I'll be more explicit. In this case, the DateTime library is being used primarily as a date formatter. The code to do so is generic, and so is unaware if it is being passed just a date, or a date with time component. System wide the timezone is set, and so it sets that always. So in this use case it is taking a day, building a DateTime object, and then asking it to format it into a different format. I assume what is happening is when not passed any time components during construction it defaults to to 0s, and then applies the timezone, which breaks because that time never actually existed. I wonder if better behavior in that circumstance would be to "default" it to the beginning of that day, rather than enforcing a specific time component that may be invalid with certain timezone and then die. Is it not a reasonable question to ask for a DateTime object for a year month and day in a given timezone, and have it return something valid? And if the beginning of that day is not 00:00:00 then given it wasn't asked to be that, it can be set to whatever it should be? On Tue, Mar 17, 2015 at 7:24 AM, Dave Rolsky via RT < bug-DateTime@rt.cpan.org> wrote: Show quoted text

> <URL: https://rt.cpan.org/Ticket/Display.html?id=102785 > > > On Mon Mar 16 16:00:44 2015, brettrann@gmail.com wrote:

> > I expected to be able to get a date object representing that day, when > > time wasn't specified. Not the library dying acting as if that was too > > hard. If the beginning of that day needs to be 20:08 then so be it.

> > There's no need to be snarky. When I asked what you expected I really > wanted to know what you thought was wrong. I missed that you didn't specify > a time in the code sample you provided. > > The offset moved from +09:39.52 to +10:00.00 at midnight, so midnight on > that day doesn't exist in the local time. You can verify this by running > this command - "zdump -v Australia/Melbourne", which outputs the following: > > Australia/Melbourne Thu Jan 31 14:20:07 1895 UT = Thu Jan 31 23:59:59 > 1895 LMT isdst=0 gmtoff=34792 > Australia/Melbourne Thu Jan 31 14:20:08 1895 UT = Fri Feb 1 00:20:08 > 1895 AEST isdst=0 gmtoff=36000 > > As you can see, it skips from 23:59:59 to 00:20:08. Time zones are weird. > > If you want to just represent dates and do date math without worrying > about times, you should create all your dates using the floating time zone, > which is a sort of "fake" zone that doesn't have any DST transitions. >

Mon Apr 27 12:15:50 2015 DROLSKY [...] cpan.org - Correspondence added

On Mon Mar 16 19:40:54 2015, brettrann@gmail.com wrote: Show quoted text

> I assume what is happening is when not passed any time components > during > construction it defaults to to 0s, and then applies the timezone, > which > breaks because that time never actually existed.

Yes, that's what is happening. Show quoted text

> I wonder if better behavior in that circumstance would be to "default" > it > to the beginning of that day, rather than enforcing a specific time > component that may be invalid with certain timezone and then die. Is > it not > a reasonable question to ask for a DateTime object for a year month > and day > in a given timezone, and have it return something valid? And if the > beginning of that day is not 00:00:00 then given it wasn't asked to be > that, it can be set to whatever it should be?

This would be nice, but I can't really change DateTime's defaults now. What I really wish I had provided was a separate date-only class, since I think that's what you want here. That all said, if you're just trying to use DateTime to format _dates_ (without times), then you should explicitly specify the "floating" time zone in all constructors and you'll get the behavior you want.

Tue Apr 28 01:36:14 2015 brettrann [...] gmail.com - Correspondence added

Subject:	Re: [rt.cpan.org #102785] 1895-02-01 Australia/Melbourne - Invalid local time for date in time zone: Australia/Melbourne
Date:	Tue, 28 Apr 2015 15:36:07 +1000
To:	"bug-DateTime [...] rt.cpan.org" <bug-DateTime [...] rt.cpan.org>
From:	brett rann <brettrann [...] gmail.com>

Yeah, fair enough. And yes, that is what I'm wanting here. I have made your recommended change and all is working fine. Thanks!

Bug #102785 for DateTime: 1895-02-01 Australia/Melbourne - Invalid local time for date in time zone: Australia/Melbourne

Preferred bug tracker