Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

[perl #115654] strptime() missing from POSIX

26 views
Skip to first unread message

l . mai @ web . de

unread,
Nov 9, 2012, 12:06:34 PM11/9/12
to bugs-bi...@rt.perl.org
# New Ticket Created by l....@web.de
# Please include the string: [perl #115654]
# in the subject line of all future correspondence about this issue.
# <URL: https://rt.perl.org:443/rt3/Ticket/Display.html?id=115654 >



This is a bug report for perl from l....@web.de,
generated with the help of perlbug 1.39 running under perl 5.16.2.


-----------------------------------------------------------------
[Please describe your issue here]

The POSIX module provides access to strftime(), but its inverse strptime() is
missing.

[Please do not change anything below this line]
-----------------------------------------------------------------
---
Flags:
category=library
severity=low
module=POSIX
---
Site configuration information for perl 5.16.2:

Configured by mauke at Thu Nov 1 15:23:47 CET 2012.

Summary of my perl5 (revision 5 version 16 subversion 2) configuration:

Platform:
osname=linux, osvers=2.6.32-5-686, archname=i686-linux
uname='linux debian-vb 2.6.32-5-686 #1 smp sun sep 23 09:49:36 utc 2012 i686 gnulinux '
config_args='-Dprefix=/home/mauke/usr -Doptimize=-O2 -flto -Dldflags=-fstack-protector -L/usr/local/lib -O2 -flto -Dlddlflags=-shared -O2 -flto -L/usr/local/lib -fstack-protector -Dcf_email=l....@web.de -Dperladmin=none -de'
hint=recommended, useposix=true, d_sigaction=define
useithreads=undef, usemultiplicity=undef
useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
use64bitint=undef, use64bitall=undef, uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='cc', ccflags ='-fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
optimize='-O2 -flto',
cppflags='-fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include'
ccversion='', gccversion='4.7.1', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
alignbytes=4, prototype=define
Linker and Libraries:
ld='cc', ldflags ='-fstack-protector -L/usr/local/lib -O2 -flto'
libpth=/usr/local/lib /lib/../lib /usr/lib/../lib /lib /usr/lib /usr/lib/i486-linux-gnu /usr/lib64
libs=-lnsl -ldl -lm -lcrypt -lutil -lc
perllibs=-lnsl -ldl -lm -lcrypt -lutil -lc
libc=/lib/libc-2.11.3.so, so=so, useshrplib=false, libperl=libperl.a
gnulibc_version='2.11.3'
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
cccdlflags='-fPIC', lddlflags='-shared -O2 -flto -L/usr/local/lib -fstack-protector'

Locally applied patches:
SAVEARGV0 - disable magic open in <ARGV>

---
@INC for perl 5.16.2:
/home/mauke/usr/lib/perl5/site_perl/5.16.2/i686-linux
/home/mauke/usr/lib/perl5/site_perl/5.16.2
/home/mauke/usr/lib/perl5/5.16.2/i686-linux
/home/mauke/usr/lib/perl5/5.16.2
/home/mauke/usr/lib/perl5/site_perl/5.16.1/i686-linux
/home/mauke/usr/lib/perl5/site_perl/5.16.1
/home/mauke/usr/lib/perl5/site_perl
.

---
Environment for perl 5.16.2:
HOME=/home/mauke
LANG=en_US.utf8
LANGUAGE (unset)
LC_COLLATE=POSIX
LD_LIBRARY_PATH=/home/mauke/usr/lib
LOGDIR (unset)
PATH=/home/mauke/perl5/perlbrew/bin:/home/mauke/.cabal/bin:/home/mauke/usr/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
PERLBREW_BASHRC_VERSION=0.55
PERLBREW_HOME=/home/mauke/.perlbrew
PERLBREW_ROOT=/home/mauke/perl5/perlbrew
PERL_BADLANG (unset)
PERL_UNICODE=SAL
SHELL=/bin/bash

Jesse Luehrs

unread,
Nov 9, 2012, 3:08:57 PM11/9/12
to perl5-...@perl.org
On Fri, Nov 09, 2012 at 09:06:34AM -0800, l....@web.de wrote:
> The POSIX module provides access to strftime(), but its inverse strptime() is
> missing.

Why is this a bug?

-doy

James E Keenan via RT

unread,
Nov 9, 2012, 7:34:50 PM11/9/12
to perl5-...@perl.org
I, too, don't think this is a bug, nor do I think it is a feature which
should be implemented and maintained by p5p (which is where POSIX.pm is
maintained).

'man 3 strptime' says this function's purpose is to "convert a string
representation of time to a time tm structure." Since the thrust of
POSIX.pm is to give POSIX identifiers "Perl-ish interfaces," my hunch is
that implementation in Perl would mean "converting a string
representation of time to a hash." Perhaps something like this
variation on an example from the GNU/Linux manpage.

%tm = strptime("2001-11-12 18:31:01");

But do we really need something like this in the core distribution --
particularly that we've got uber-sophisticated CPAN modules like
DateTime to handle date/time manipulation?

Naah.

Thank you very much.
Jim Keenan

---
via perlbug: queue: perl5 status: open
https://rt.perl.org:443/rt3/Ticket/Display.html?id=115654

Eric Brine

unread,
Nov 10, 2012, 10:28:30 PM11/10/12
to perlbug-...@perl.org, perl5-...@perl.org
On Fri, Nov 9, 2012 at 7:34 PM, James E Keenan via RT <perlbug-...@perl.org> wrote:
But do we really need something like this in the core distribution --
particularly that we've got uber-sophisticated CPAN modules like
DateTime to handle date/time manipulation?

Specifically, DateTime::Format::Strptime

Dr.Ruud

unread,
Nov 11, 2012, 2:36:34 AM11/11/12
to perl5-...@perl.org
On 2012-11-11 04:28, Eric Brine wrote:
> James E Keenan:

>> But do we really need something like this in the core distribution --
>> particularly that we've got uber-sophisticated CPAN modules like
>> DateTime to handle date/time manipulation?
>
> Specifically, DateTime::Format::Strptime

And also:

Time::Piece->strptime(STRING, FORMAT)
# see strptime man page. Creates a new
# Time::Piece object

--
Ruud

Leon Timmermans

unread,
Nov 14, 2012, 4:22:07 PM11/14/12
to perl5-...@perl.org, bugs-bi...@rt.perl.org
On Fri, Nov 9, 2012 at 6:06 PM, l....@web.de <perlbug-...@perl.org> wrote:
> The POSIX module provides access to strftime(), but its inverse strptime() is
> missing.

POSIX defines more than a 1000 functions, I think less than 200 are
described in POSIX.pm and half those are not really implemented (too
lazy to count the exact numbers). POSIX.pm is remarkable resistant to
additional functions, in fact I think only 2 or 3 have been added in
its 18 years of history (lchown is one of them, I forgot the others).
I don't necessarily think it's bad to add some more stuff to it (like
apparently everyone else, I have my own pet peeves), but in general
more CPAN modules (I have a few in the POSIX:: namespace already, and
know plenty of space for others) are preferable.

Leon

Eric Brine via RT

unread,
Nov 14, 2012, 10:03:24 PM11/14/12
to perl5-...@perl.org
I have closed this ticket: Not a bug.

Paul LeoNerd Evans

unread,
Nov 15, 2012, 6:40:44 AM11/15/12
to Dr.Ruud, Perl 5 Porters
On Sun, Nov 11, 2012 at 08:36:34AM +0100, Dr.Ruud wrote:
> Time::Piece->strptime(STRING, FORMAT)
> # see strptime man page. Creates a new
> # Time::Piece object

Time::Piece's version suffers a number of problems.

1) It can't preserve partial fields (e.g. sec/min/hour) while parsing
others (e.g. mday/mon/year)

2) It can't extract a partial match from a string yielding the end of
the match (e.g. "Mon 1st Oct and some following text here").

The version I proposed for core's POSIX.xs solves both of these.

--
Paul "LeoNerd" Evans

leo...@leonerd.org.uk
ICQ# 4135350 | Registered Linux# 179460
http://www.leonerd.org.uk/
signature.asc

Paul LeoNerd Evans

unread,
Nov 15, 2012, 6:39:18 AM11/15/12
to James E Keenan via RT, Perl 5 Porters
On Fri, Nov 09, 2012 at 04:34:50PM -0800, James E Keenan via RT wrote:
> I, too, don't think this is a bug, nor do I think it is a feature which
> should be implemented and maintained by p5p (which is where POSIX.pm is
> maintained).
>
> 'man 3 strptime' says this function's purpose is to "convert a string
> representation of time to a time tm structure." Since the thrust of
> POSIX.pm is to give POSIX identifiers "Perl-ish interfaces," my hunch is
> that implementation in Perl would mean "converting a string
> representation of time to a hash." Perhaps something like this
> variation on an example from the GNU/Linux manpage.
>
> %tm = strptime("2001-11-12 18:31:01");
>
> But do we really need something like this in the core distribution --
> particularly that we've got uber-sophisticated CPAN modules like
> DateTime to handle date/time manipulation?

I've written one. For core's POSIX.xs

It's complete. It has tests. It has documentation. It has everything
required.

I got into stupid arguments about non-issues on p5p@ before about trying
to get it included.

If you want this included (and I really do) please can we reopen a
discussion on it so it can be done?

Thanks,
signature.asc

Steve Peters

unread,
Nov 27, 2012, 4:24:06 PM11/27/12
to Paul LeoNerd Evans, James E Keenan via RT, Perl 5 Porters
On Thu, Nov 15, 2012 at 5:39 AM, Paul LeoNerd Evans <leo...@leonerd.org.uk> wrote:
On Fri, Nov 09, 2012 at 04:34:50PM -0800, James E Keenan via RT wrote:
> I, too, don't think this is a bug, nor do I think it is a feature which
> should be implemented and maintained by p5p (which is where POSIX.pm is
> maintained).
>
> 'man 3 strptime' says this function's purpose is to "convert a string
> representation of time to a time tm structure."   Since the thrust of
> POSIX.pm is to give POSIX identifiers "Perl-ish interfaces," my hunch is
> that implementation in Perl would mean "converting a string
> representation of time to a hash."  Perhaps something like this
> variation on an example from the GNU/Linux manpage.
>
>   %tm = strptime("2001-11-12 18:31:01");


Umm....

       struct tm *gmtime(const time_t *timep);
       struct tm *gmtime_r(const time_t *timep, struct tm *result);

       struct tm *localtime(const time_t *timep);
       struct tm *localtime_r(const time_t *timep, struct tm *result);

If a POSIX::strptime is implemented, it should be returning an array compatible with localtime and gmtime.  Any other implementation would be bizarre and make it incompatible with other POSIX functions descended functions that are returning a stuct tm*.

I've written one. For core's POSIX.xs

It's complete. It has tests. It has documentation. It has everything
required.

I got into stupid arguments about non-issues on p5p@ before about trying
to get it included.

If you want this included (and I really do) please can we reopen a
discussion on it so it can be done?

 
I, for one, would like to see the code, and really do not see a compelling reason why it shouldn't be included.  Obviously, a separate module would allow it to be used in earlier versions of Perl that the one where the new function is included, but that's a very specious argument to exclude it.

Steve
0 new messages