New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
localtime corruption #7907
Comments
From dpfeiffer@amadeus.netThis is a bug report for perl from occitan@esperanto.org, localtime returns rubbish outside of -~0/2..~0/2. The first quarter of Flags: This perlbug was built using Perl v5.8.6 - Sat Mar 19 17:33:54 UTC 2005 Site configuration information for perl v5.8.6: Configured by abuild at Sat Mar 19 17:29:44 UTC 2005. Summary of my perl5 (revision 5 version 8 subversion 6) configuration: Locally applied patches: @INC for perl v5.8.6: Environment for perl v5.8.6: PATH=/home/pfeiffer/bin:/usr/local/bin:/bin:/usr/bin::/sbin:/usr/sbin:/usr/games:/opt/kde3/bin:/opt/gnome/bin:/usr/bin/X11:/opt/OpenOffice.org1.1.3/program:/opt/MKS/IntegrityClient/bin:/usr/lib/java/jre/bin -- |
From @rgsDaniel Pfeiffer (via RT) wrote:
Perl can't do better than the OS here. |
The RT System itself - Status changed from 'new' to 'open' |
@rgs - Status changed from 'open' to 'rejected' |
From perl5-porters@ton.iguana.beIn article <20050512140047.3d09ea_c@grubert.mandrakeso_t.com>,
Actually, I suppose we could. We don't *have* to use the libc |
From @JohnPeacockTon Hospel wrote:
libtai is public domain: http://cr.yp.to/libtai.html the problem being that it requires a 64bit int which Win32 makes John -- |
From dpfeiffer@amadeus.netHallo Rafael, Inconsistencies of this kind are a terrible trap! For one thing the doc mit freundlichen Grü�en / best regards -- From: "Rafael Garcia-Suarez via RT" <perlbug-followup@perl.org> on To: cc: Subject: Daniel Pfeiffer (via RT) wrote:
Perl can't do better than the OS here. |
From @JohnPeacockDaniel Pfeiffer wrote:
It's not a lie; virtually all modern operating systems use a 32-bit time value http://www.2038bug.com/ for why this is a problem. Perl could work around it by using a different time The range of the time_t values _is_ documented several places, like here in Please note, however, that the range of dates that can be actually be HTH John -- |
From @schwernOn Fri, May 13, 2005 at 07:38:12AM -0400, John Peacock wrote:
A) This assumes new Perl programmers already have knowledge of C or similar B) There's nothing that says because C made this mistake that Perl should,
Time::Local is the *only* place its documented (there's an offhand mention in Daniel is right, it is a trap and it is poorly documented. What should be 1) Document that there is a system dependent limitation perlfunc and perlport 2) Add a probe to Configure to check what the date range of localtime() is 3) Have Perl use its own 64 bit time library. -- |
From @JohnPeacockMichael G Schwern wrote:
Anyone feeding random numbers into localtime shouldn't be considered a
Yeah, in Perl 6. That's down the hall. ;-)
This gets my vote as the only realistic solution for Perl5. Although we John 1. I like this page: http://developer.apple.com/technotes/tn/tn1049.html which correctly points out that the Mac never had a Y2K problem without -- |
From @schwernOn Fri, May 13, 2005 at 04:40:56PM -0400, John Peacock wrote:
Let's be civil and sane here and not a bunch of old Unix farts. This is Here's a simple scenario where a user is surprised by localtime's behavior You have dates stored as unix time with math done in unix time. One of
Parrot is likely to have to do the same thing Perl 5 would: have its own
Agreeing that its a good idea is orthoganal to its implementation difficulty. What about #2: the warning that you've overflowed the native localtime()?
I don't think I understand how this is relevant or where Y2K comes in. I -- |
From @JohnPeacockMichael G Schwern wrote:
I'm not trying to be. Daniel reported that he was checking both very small and It's also not specific to Unix; even though Windows stores it's time in a 64bit http://www.codeproject.com/datetime/time64.asp
And how is Perl going to deal with that? Do we go with the Mac's unsigned 32bit http://cr.yp.to/proto/utctai.html Or do we standardize on UTC, which is civil time based on TAI plus leap seconds.
The problem with a custom date library is that it is actually very hard to I won't try and replicate the information in the very good resources listed at: http://datetime.perl.org/resources.html but the basic matter is that until the TAI/UTC standardization in 1970, there The reason I mentioned the Mac epoch is that there were still a number of
If you want to write Configure probes, go right ahead. You should probably John -- |
From @tamiasOn Fri, May 13, 2005 at 12:02:22PM +0200, Daniel Pfeiffer wrote:
I think you've misunderstood that part of the documentation. In scalar context, "localtime()" returns the ctime(3) value: $now_string = localtime; # e.g., "Thu Oct 13 04:54:34 1994" This scalar value is not locale dependent, see perllocale, but Regardless of your locale, the *formatting* of the scalar value will always The conversion from an integer time to a time struct, however, is dependent Ronald |
From @demerphqOn 5/13/05, Ronald J Kimball <rjk@tamias.net> wrote:
And is probably a good example of a trap that Perl6/Parrot should avoid. Having built ins return language specific date formats is a crappy system. Localtime should have returned an ISO compliant string like -- |
From @schwernOn Fri, May 13, 2005 at 09:40:33PM -0400, John Peacock wrote:
I understand you're trying to show this is a hard problem but just because
Don't know and it doesn't matter for the purposes of this conversation. Its
Binary search should be efficient enough. Something like 64 comparisons Except...*shudder*...metaconfig and shell programming. I'll take a crack -- |
From @TuxOn Sun, 15 May 2005 14:50:28 -0700, Michael G Schwern <schwern@pobox.com>
If it's sensible, I'll clean it up and backport to the real metaunits :) For now, don't you care about *my* problems. Just do what suits you best and -- |
From @schwern
The attached patch implements this suggestion by mentioning the problem |
From @schwernlocaltime1.patch--- ./pod/perlfunc.pod 2005/05/16 22:03:37 1.1
+++ ./pod/perlfunc.pod 2005/05/16 22:04:29
@@ -2185,6 +2185,8 @@
instead a Perl builtin. To get somewhat similar but locale dependent date
strings, see the example in L</localtime>.
+See L<perlport/gmtime> for portability concerns.
+
=item goto LABEL
=item goto EXPR
@@ -2581,6 +2583,8 @@
Note that the C<%a> and C<%b>, the short forms of the day of the week
and the month of the year, may not necessarily be three characters wide.
+
+See L<perlport/localtime> for portability concerns.
=item lock THING
--- ./pod/perlport.pod 2005/05/16 21:59:12 1.1
+++ ./pod/perlport.pod 2005/05/16 22:02:57
@@ -1783,6 +1783,10 @@
This operator is implemented via the File::Glob extension on most
platforms. See L<File::Glob> for portability information.
+=item gmtime EXPR
+
+Same portability caveats as L<localtime>.
+
=item ioctl FILEHANDLE,FUNCTION,SCALAR
Not implemented. (VMS)
@@ -1815,6 +1819,13 @@
Hard links are implemented on Win32 (Windows NT and Windows 2000)
under NTFS only.
+
+=item localtime EXPR
+
+Because Perl currently relies on the native standard C localtime()
+function, it is only safe to use times between 0 and (2**31)-1. Times
+outside this range may result in unexpected behavior depending on your
+operating system's implementation of localtime().
=item lstat FILEHANDLE
|
@schwern - Status changed from 'rejected' to 'open' |
From @schwern
Attached is an implementation of this in Perl in the hopes that someone The expected values for a 64bit clean gmtime() need to be filled in as I |
From @schwernI posted up a few followups and patches to this bug via the RT web interface -- |
From @rspier
There is no automatic forwarding from the web interface to the list. This is how it has always been. Mail loops are bad. -R |
From @schwernOn Tue, May 17, 2005 at 10:48:46AM -0700, Robert Spier wrote:
This kinda sucks, a lot of people probably don't realize this and don't Is there a way to break the mail loop perhaps using message-ids? -- |
From @schwernI posted two patches via RT which can be found here. One documents the date range limitations of localtime and gmtime. The other is a proof-of-concept implementation to scan for the limitations -- |
From @nwc10On Fri, May 13, 2005 at 09:40:33PM -0400, John Peacock wrote:
I would assume here that if POSIX turns out currently to be stating this and This isn't saying that it's good. Merely that it's big enough to be a On the real issue, I think that documenting the trap and adding a TODO and It worked for trie optimisations. :-) Nicholas Clark |
From @gisleNicholas Clark <nick@ccl4.org> writes:
This bug in the specs was fixed in POSIX:2001. See --Gisle |
From @JohnPeacockGisle Aas wrote:
Excellent! Based on the history (IEEE Std 1003.1 was originally published in John -- |
From @JohnPeacockNicholas Clark wrote:
Well, the reality of the thing is that current 32-bit implementations of
I agree. It actually occurred to me that if we only wanted to fix localtime (to John -- |
From dpfeiffer@amadeus.netJohn Peacock wrote:
I had a rather realistic application: A colleague claimed that most bad To my surprise one value came excessively frequently, those were the mit freundlichen Grüßen / best regards -- |
From wolfgang.laun@alcatel.atDaniel Pfeiffer wrote:
There is indeed a connection between Friday and 13. It is, This, then, is the correct statement: The 13th day of a month To check, you have to analyze a full Gregorian Period of 400aG The maximum for Friday is 688, which is only 0.33% more than Cheers |
From @schwernMy patch to the localtime documentation appears to have been lost in the -- |
From @schwernlocaltime.patch--- pod/perlfunc.pod 2005/05/26 20:38:07 1.1
+++ pod/perlfunc.pod 2005/05/26 20:38:17
@@ -2186,6 +2186,8 @@
instead a Perl builtin. To get somewhat similar but locale dependent date
strings, see the example in L</localtime>.
+See L<perlport/gmtime> for portability concerns.
+
=item goto LABEL
=item goto EXPR
@@ -2582,6 +2584,8 @@
Note that the C<%a> and C<%b>, the short forms of the day of the week
and the month of the year, may not necessarily be three characters wide.
+
+See L<perlport/localtime> for portability concerns.
=item lock THING
--- pod/perlport.pod 2005/05/26 20:38:13 1.1
+++ pod/perlport.pod 2005/05/26 20:38:34
@@ -1773,6 +1773,10 @@
This operator is implemented via the File::Glob extension on most
platforms. See L<File::Glob> for portability information.
+=item gmtime
+
+Same portability caveats as L<localtime>.
+
=item ioctl FILEHANDLE,FUNCTION,SCALAR
Not implemented. (VMS)
@@ -1805,6 +1809,13 @@
Hard links are implemented on Win32 (Windows NT and Windows 2000)
under NTFS only.
+
+=item localtime
+
+Because Perl currently relies on the native standard C localtime()
+function, it is only safe to use times between 0 and (2**31)-1. Times
+outside this range may result in unexpected behavior depending on your
+operating system's implementation of localtime().
=item lstat
|
From @rgsMichael G Schwern wrote:
Thanks, applied as #24593. |
@rgs - Status changed from 'open' to 'resolved' |
Migrated from rt.perl.org#35420 (status was 'resolved')
Searchable as RT35420$
The text was updated successfully, but these errors were encountered: