Bug #27370 for Time-modules: Timezone support breaks for daylight savings boundaries

Fri Jun 01 11:25:22 2007 cpan [...] jibsheet.com - Ticket created

parsedate accepts a ZONE parameter that can either be an offset or a short timezone name (which unfortunately has conflicts). This causes problems when you hand parsedate an offset and ask it to parse a future date that isn't in daylight savings while your code is currently running under a daylight savings timezone. I've attached code that shows the problem we're having, but I'll summarize. We convert our stored timezone (America/New_York) into an offset (currently -0400) and hand that to parsedate along with a user provided input. That could be tomorrow, or it could be 2009-12-24. I'm showing the test with 2009-12-24 for simplicity, but I could easily construct this to run on 2007-11-04 when the US cuts over from daylight savings. When we get back seconds and turn them into a date in the correct timezone, we end up with one day earlier at 23:00. I have to realize that this is wrong in my code and then re-parse with the -0500 offset. If parsedate took timezone names, rather than short names, this would "work".

Subject:

parsedate

Download parsedate
application/octet-stream 907b

Message body not shown because it is not plain text.

Fri Jun 01 11:55:27 2007 cpan [...] jibsheet.com - Subject changed from (no value) to 'Timezone support breaks for daylight savings boundaries'

Fri May 20 21:16:37 2011 MUIR [...] cpan.org - Correspondence added

If parsedate took timezone names then there would be ambiguous times. What would 1:23 AM on the fallback day mean? I'm open to doing it anyway especially with a patch. -Dave On Fri Jun 01 11:25:22 2007, FALCONE wrote: Show quoted text

> parsedate accepts a ZONE parameter that can either be an offset or a > short timezone name (which unfortunately has conflicts). This causes > problems when you hand parsedate an offset and ask it to parse a future > date that isn't in daylight savings while your code is currently running > under a daylight savings timezone. > > I've attached code that shows the problem we're having, but I'll > summarize. We convert our stored timezone (America/New_York) into an > offset (currently -0400) and hand that to parsedate along with a > user provided input. That could be tomorrow, or it could be 2009-12-24. > I'm showing the test with 2009-12-24 for simplicity, but I could easily > construct this to run on 2007-11-04 when the US cuts over from daylight > savings. When we get back seconds and turn them into a date in the > correct timezone, we end up with one day earlier at 23:00. I have to > realize that this is wrong in my code and then re-parse with the -0500 > offset. If parsedate took timezone names, rather than short names, this > would "work".

Fri May 20 21:16:38 2011 The RT System itself - Status changed from 'new' to 'open'

Mon May 23 12:25:20 2011 cpan [...] jibsheet.com - Correspondence added

Subject:	Re: [rt.cpan.org #27370] Timezone support breaks for daylight savings boundaries
Date:	Mon, 23 May 2011 12:25:07 -0400
To:	David_Muir_Sharnoff via RT <bug-Time-modules [...] rt.cpan.org>
From:	Kevin Falcone <cpan [...] jibsheet.com>

On Fri, May 20, 2011 at 09:16:38PM -0400, David_Muir_Sharnoff via RT wrote: Show quoted text

> If parsedate took timezone names then there would be ambiguous times.

Only if you used short names. How is using America/New_York ambiguous? Show quoted text

> What would 1:23 AM on the fallback day mean? > > I'm open to doing it anyway especially with a patch.

At this point, we removed our dep on Time::ParseDate 3-4 years ago because of this and other bugs, so unfortunately work won't cover me patching in the new feature. Please feel free to resolve this bug. -kevin

Mon May 23 12:44:30 2011 rt.cpan [...] sartak.org - Cc SARTAK added

Fri Oct 28 21:34:05 2011 cjm [...] cpan.org - Correspondence added

On Mon, May 23, 2011 11:25:20 AM, FALCONE wrote: Show quoted text

> On Fri, May 20, 2011 at 09:16:38PM -0400, David_Muir_Sharnoff via RT

wrote: Show quoted text

> > If parsedate took timezone names then there would be ambiguous times.

> > Only if you used short names. How is using America/New_York > ambiguous?

It's ambiguous because "6-Nov-2011 1:23am" occurs twice in the America/New_York timezone, once at 05:23 UTC (before the clocks are put back), and again at 06:23 UTC (after the clocks have been put back). That said, this would still be a useful feature, because there are few ambiguous times, and they aren't entered often. (That's why we change DST at 2am.) Just document which of the two possible times you'll return (e.g. the one that occurs first).

Fri Oct 28 21:44:11 2011 cjm [...] cpan.org - Correspondence added

On Fri, Oct 28, 2011 8:34:05 PM, CJM wrote: Show quoted text

> Just document which of the two possible times you'll > return (e.g. the one that occurs first).

It occurs to me that there are some odd corner cases involving PREFER_FUTURE and PREFER_PAST interacting with ambiguous times. For example, what about parsing "6-Nov-2011 1:23am" America/NewYork at 06:20 UTC with PREFER_FUTURE (assuming you normally return the ambiguous time occurring first)?

Fri Oct 28 22:25:13 2011 cpan [...] jibsheet.com - Requestor FALCONE deleted

Fri Oct 28 22:26:38 2011 cpan [...] jibsheet.com - Correspondence added

As mentioned 6 months ago, I removed our work dependency on this module 4 years ago because of this and enough other bugs and asked that it be resolved. I've now removed myself as a requestor and will attempt to resolve it for you. -kevin On Fri Oct 28 21:34:05 2011, CJM wrote: Show quoted text

> On Mon, May 23, 2011 11:25:20 AM, FALCONE wrote:

> > On Fri, May 20, 2011 at 09:16:38PM -0400, David_Muir_Sharnoff via RT

> wrote:

> > > If parsedate took timezone names then there would be ambiguous times.

> > > > Only if you used short names. How is using America/New_York > > ambiguous?

> > It's ambiguous because "6-Nov-2011 1:23am" occurs twice in the > America/New_York timezone, once at 05:23 UTC (before the clocks are put > back), and again at 06:23 UTC (after the clocks have been put back). > > That said, this would still be a useful feature, because there are few > ambiguous times, and they aren't entered often. (That's why we change > DST at 2am.) Just document which of the two possible times you'll > return (e.g. the one that occurs first).