One for the Perl gurus on the list- not a major problem but more of a
philosophical debate, while doing some date related work I noticed that
sprintf() & printf() didn't behave as I expected them to, the following
snippet:
#!perl-w
printf("%2d",((localtime(time))[5])),"\n";
yields '101' not '01' as I expected (which was: that this would 'round
down' the number much in the way it 'rounds up' decimals), as I was looking
to build a short date (ending in '/01' rather than '2001' ) I simply did:
#!perl-w
printf("%2d",((localtime(time))[5]-100)),"\n";
and got '1'. Puzzled I went on to test why and found, _gasp_, the padding
used for non decimal integers by [s]printf() are spaces and not zeros.
Not only that but _none_ of the established sources (PODs, CAMEL,
COOKBOOK) even touched on this (I think the PODs mumbled something about
the strings being padded by zeros or spaces depending on circumstance but
didn't elucidate beyond this) -
so my question is:
considering how data is normally markedly divided into numbers and strings
(to the point of giving each dedicated comparison operators) why don't
printf() and sprintf() pad numbers with zeros and strings with spaces?
Robin
- Re: [MacPerl] Sprintf() huh? robinmcf
- Re: [MacPerl] Sprintf() huh? Detlef Lindenthal
- Re: [MacPerl] Sprintf() huh? John W Baxter
- Re: [MacPerl] Sprintf() huh? David Graff
- Re: [MacPerl] Sprintf() huh? Jim Correia
- Re: [MacPerl] Sprintf() huh? robinmcf
- Re: [MacPerl] Sprintf() huh? Ronald J Kimball
- Re: [MacPerl] Sprintf() huh? Bart Lateur
- Re: [MacPerl] Sprintf() huh? robinmcf
- Re: [MacPerl] Sprintf() huh? John W Baxter