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

Reply via email to