Skip Menu |

This queue is for tickets about the TimeDate CPAN distribution.

Report information
The Basics
Id: 105031
Status: new
Priority: 0/
Queue: TimeDate

Owner: Nobody in particular
Requestors: revhippie [...]

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)

MIME-Version: 1.0
X-Spam-Status: No, score=-2.699 tagged_above=-99.9 required=10 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
X-Spam-Flag: NO
content-type: text/plain; charset="utf-8"
Message-ID: <CABj-zRQEpyG=+414+w20fe02SUd9EvBapMW0uwp=2PfiaWze1A [...]>
X-Received: by with SMTP id u202mr4953749oif.10.1433645211210; Sat, 06 Jun 2015 19:46:51 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at
X-Spam-Score: -2.699
Received: from localhost (localhost []) by (Postfix) with ESMTP id 043C12404F9 for <cpan-bug+TimeDate [...]>; Sat, 6 Jun 2015 22:47:11 -0400 (EDT)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QutNKAnayc-3 for <cpan-bug+TimeDate [...]>; Sat, 6 Jun 2015 22:47:09 -0400 (EDT)
Received: from ( []) by (Postfix) with SMTP id 92FDF2401A8 for <bugs-TimeDate [...]>; Sat, 6 Jun 2015 22:47:09 -0400 (EDT)
Received: (qmail 13007 invoked by alias); 7 Jun 2015 02:47:09 -0000
Received: from (HELO ( by (qpsmtpd/0.28) with ESMTP; Sat, 06 Jun 2015 19:47:02 -0700
Received: by obbgp2 with SMTP id gp2so55409508obb.2 for <bugs-TimeDate [...]>; Sat, 06 Jun 2015 19:46:51 -0700 (PDT)
Received: by with HTTP; Sat, 6 Jun 2015 19:46:51 -0700 (PDT)
Authentication-Results: (amavisd-new); dkim=pass header.i= [...]
Delivered-To: cpan-bug+TimeDate [...]
Subject: Date::Parse -- four digit years translated to the future
Return-Path: <revhippie [...]>
X-RT-Mail-Extension: timedate
X-Original-To: cpan-bug+TimeDate [...]
Dkim-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=k1R9x3yr8P83SZs5unaDza8BQwZirZER+YwLEcveJqY=; b=QkL5gv8qU4RD3kPkvRhRGpBpFgQ+j5/kVdZ5KYERzAySayb1LxigoiV5Yv4aib3dxc kLYDacNcv3iE0Z9VYum7QGeHNq2hFp84n0dbqOWHQ4wYsU00KDQVzQVpnD99iNPT5rUE csRh7IH95XNX1mRpEHEytKEYeiw5tBsVnOwThOW/4jORmNvmE1lXVQV8KZS324Dex7zN ZMN06Nx1+LLsVjs/KuU1GoHEfxSt2RKurcSc8RbI1Yyx0zHRB9ng9zm+CYozBmffUeNK +CjAiUKNTlHdqkWpUJt8rYZhPlC5JVDMhcrdE4XBkS9ZinNRsAL+hJvv5sdV/6t/Be+d LgCw==
Date: Sat, 6 Jun 2015 21:46:51 -0500
To: bugs-TimeDate [...]
From: Jim Davis <revhippie [...]>
X-RT-Original-Encoding: utf-8
X-RT-Interface: Email
Content-Length: 1192
Download (untitled) / with headers
text/plain 1.1k
I think bug #53413 may have been misunderstood. After str2time uses strptime to break up the incoming date, it passes the result (with $year - 1900) to Time::Local::timelocal. timelocal uses a sliding window to determine if the year should be 19xx or 20xx, completely throwing away the *known* four-digit year that we sent to str2time. For example: say "$_\t", str2time($_) for qw( 1965-12-31 1966-01-01 ); generates: 1965-12-31 3029464800 # 2065 1966-01-01 -126208800 # 1966 (This will produce different results if run a year from now -- they'll both come back in the 21st century instead of the 20th.) This might not be a bug, but it's certainly surprising behavior. The window is documented in Time::Local, but I think Date::Parse shouldn't expose end-users to that oddity. (Perhaps by adding 1900 to the strpdate output if it notices it's been passed a complete year.) (The Date::Parse documentation refers to an early limit as 1901-12-17 00:00:00 GMT, which is currently about fifty years off.) My apologies if I appear to be beating a dead horse. -- Jim Davis -- Jim Davis

This service is sponsored and maintained by Best Practical Solutions and runs on infrastructure.

Please report any issues with to