Check for military time

Derek Turner

unread,

Oct 20, 2015, 2:57:47 PM10/20/15

to

Is there a quick and dirty way to check that

substr($string, 0 ,3) is a valid military time, ie. 0000-2359?

tia

Derek

Derek Turner

unread,

Oct 20, 2015, 3:00:25 PM10/20/15

to

sorry, that should, of course, read ($string, 0, 4)

Richard Yates

unread,

Oct 21, 2015, 12:36:08 AM10/21/15

to

This seems to work, but I did not test all cases:

echo (strtotime($time)) ? 'Pass' : 'Fail';

Thomas 'PointedEars' Lahn

unread,

Oct 21, 2015, 7:55:30 AM10/21/15

to

Derek Turner wrote:

> Is there a quick and dirty way to check that
>
> substr($string, 0 ,3) is a valid military time, ie. 0000-2359?

Yes.

--
PointedEars
Zend Certified PHP Engineer
Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

M. Strobel

unread,

Oct 21, 2015, 2:56:22 PM10/21/15

to

On 21.10.2015 13:55, Thomas 'PointedEars' Lahn wrote:
> Derek Turner wrote:
>
>> Is there a quick and dirty way to check that
>>
>> substr($string, 0 ,3) is a valid military time, ie. 0000-2359?
>
> Yes.
>

"Can you tell me what time it is?"

"Yes."

Kindergarten.

/Str.

Lew Pitcher

unread,

Oct 21, 2015, 4:12:55 PM10/21/15

to

On Wednesday October 21 2015 00:35, in comp.lang.php, "Richard Yates"

PHP Version 5.4.45

I tried all integer test cases between 0000 and 2599, and found that this test
seems to fail on the range "1960" to "1999". On the off chance that the
strtotime() call interpreted its argument as a date, I modified the argument
to explicitly indicate military time (by prefixing it with a 't'). Still, the
same 40 errors occurred, where "t1960" through "t1999" resulted in
strtotime() returning an integer instead of FALSE.

Here's the test code
<html>
<head><title>Test time</title></head>
<body>
<ul>
<?php
$success = 0;
$failed = 0;

for ($ts = 0; $ts < 2600; ++$ts)
{
$time = sprintf("t%04.4u",$ts);
$expect = ((floor($ts/100) <= 24) && ($ts % 100 < 60)) ? 'Pass' : 'Fail';
$result = (strtotime($time)) ? 'Pass' : 'Fail';
$matched = ($expect == $result) ? 'Success' : 'Failed';
printf("<li>%s - %s: expected %s, got %s</li>\n",
$time,$matched,$expect,$result);
if ($matched == 'Success')
++$success;
else
++$failed;
}
?>
</ul>
<?php
printf("%u Successful cases, %u failures\n",$success,$failed);
?>
</body>
</html>

--
Lew Pitcher
"In Skills, We Trust"
PGP public key available upon request

Jerry Stuckle

unread,

Oct 21, 2015, 4:48:23 PM10/21/15

to

What do you expect? He couldn't find someone's code to copy/paste.

--
==================
Remove the "x" from my email address
Jerry Stuckle
jstu...@attglobal.net
==================

Jerry Stuckle

unread,

Oct 21, 2015, 10:38:22 PM10/21/15

to

Your logic is fallacious. The following code works and displays invalid
times:

<?php
$success = 0;
$failed = 0;

for ($ts = 0; $ts < 2600; ++$ts)
{

$time = sprintf("%04.4u",$ts);
$result = (strtotime($time));
if ($result)
++$success;
else {
++$failed;
printf("%s failed\n", $time);

}
}
printf("%u Successful cases, %u failures\n",$success,$failed);
?>

Thomas 'PointedEars' Lahn

unread,

Oct 22, 2015, 5:13:07 AM10/22/15

to

Lew Pitcher wrote:

> […] "Richard Yates" […] wrote:
>> On 20 Oct 2015 19:00:19 GMT, Derek Turner <frd...@suremail.je> wrote:
>>> On Tue, 20 Oct 2015 18:57:34 +0000, Derek Turner wrote:
>>>> Is there a quick and dirty way to check that
>>>>
>>>> substr($string, 0 ,3) is a valid military time, ie. 0000-2359?

>>> sorry, that should, of course, read ($string, 0, 4)
>>
>> This seems to work, but I did not test all cases:
>>
>> echo (strtotime($time)) ? 'Pass' : 'Fail';
>
> PHP Version 5.4.45
>
> I tried all integer test cases between 0000 and 2599, and found that this
> test seems to fail on the range "1960" to "1999". On the off chance that

> the strtotime() call interpreted its argument as a date, […]

Both of you are overthinking the problem. Compared to this, a solution
based on string comparison (left as an exercise for the reader) is a one-or-
two-liner (after all, the request said “quick and dirty”).

For another approach, consider <http://php.net/date_parse_from_format>,
which can serve as a substitute on Windows where, according to the PHP
manual, <http://php.net/strptime> is unavailable.

Stephan Elinghaus

unread,

Oct 22, 2015, 7:16:57 AM10/22/15

to

Am 2015-10-20 hat Derek Turner geschrieben:

> Is there a quick and dirty way to check that
>
> substr($string, 0 ,3) is a valid military time, ie. 0000-2359?

Maybe this works for you:
<?php
$string="1534";
if(preg_match("/[012](((?<=2)[0123])|(?<!2)[0-9])[[0-5][0-9]/",$string))
echo "is valid";
else echo "is not valid";
?>

--
[no signature today]

Thomas 'PointedEars' Lahn

unread,

Oct 22, 2015, 9:11:56 AM10/22/15

to

Stephan Elinghaus wrote:

> Am 2015-10-20 hat Derek Turner geschrieben:
>> Is there a quick and dirty way to check that
>>
>> substr($string, 0 ,3) is a valid military time, ie. 0000-2359?
>
> Maybe this works for you:
> <?php
> $string="1534";
> if(preg_match("/[012](((?<=2)[0123])|(?<!2)[0-9])[[0-5][0-9]/",$string))

Much too complicated, and still not completely safe (you have not anchored
the expression, neither on beginning or end of string or line, whitespace
nor non-digits). Consider instead:

if (preg_match('/^(?:[01]\\d|2[0-3])[0-5]\\d$/', $string))

Test code:

$ php -r 'foreach (range(-1, 24) as $h) foreach (range(-1, 60) as $m) { echo
preg_match("/^(?:[01]\\d|2[0-3])[0-5]\\d$/", sprintf("%02d", $h) .
sprintf("%02d", $m)); if ($m === 60) echo "\n"; }'

You should get a box of zeros filled only with ones (because '0' is the
string representation of “false”, and '1' of “true”). The zeros are (quite
literally) the edge cases that must not match, the ones the proper time
strings.

> echo "is valid";
> else echo "is not valid";

With all such constructs, consider instead:

echo ($boolean) ? $ifTrue : $ifFalse;

This is particularly useful if you can use “<?= … ?>” to just output the
(string representation of) the result of an expression.

> ?>

Avoid ending PHP files with that; you may be accidentally outputting
trailing whitespace otherwise.

Jerry Stuckle

unread,

Oct 22, 2015, 10:23:49 AM10/22/15

to

On 10/22/2015 9:11 AM, Thomas 'PointedEars' Lahn wrote:
> Stephan Elinghaus wrote:
>
>> Am 2015-10-20 hat Derek Turner geschrieben:
>>> Is there a quick and dirty way to check that
>>>
>>> substr($string, 0 ,3) is a valid military time, ie. 0000-2359?
>>
>> Maybe this works for you:
>> <?php
>> $string="1534";
>> if(preg_match("/[012](((?<=2)[0123])|(?<!2)[0-9])[[0-5][0-9]/",$string))
>
> Much too complicated, and still not completely safe (you have not anchored
> the expression, neither on beginning or end of string or line, whitespace
> nor non-digits). Consider instead:
>
> if (preg_match('/^(?:[01]\\d|2[0-3])[0-5]\\d$/', $string))
>

Much too complicated.

if (strtotime($string"))

works perfectly.

</snip>

> Avoid ending PHP files with that; you may be accidentally outputting
> trailing whitespace otherwise.
>

Another stoopid comment by the troll.

Lew Pitcher

unread,

Oct 22, 2015, 10:44:08 AM10/22/15

to

On Wednesday October 21 2015 22:38, in comp.lang.php, "Jerry Stuckle"

I disagree. You will have to prove your statement.

> The following code works and displays invalid
> times:
>
> <?php
> $success = 0;
> $failed = 0;
>
> for ($ts = 0; $ts < 2600; ++$ts)
> {
> $time = sprintf("%04.4u",$ts);
> $result = (strtotime($time));
> if ($result)
> ++$success;
> else {
> ++$failed;
> printf("%s failed\n", $time);
>
> }
> }
> printf("%u Successful cases, %u failures\n",$success,$failed);
> ?>

Results in
1540 Successful cases, 1060 failures

But, in the military clock, there are 25 hours (00 through 24) and 60 minutes
per hour (00 through 59). Thus, in 2600 test cases, ranging sequentially from
0000 through 2599, there should be 25x60 successes 25 hours, with 60 values
inside of the 00-59 range). That means 1500 successes in 2600 test cases.

But, your logic came up with 1540 successes. Apparently, your code got
40 "wrong" timestamps wrong. Now, Jerry, *which* 40 were wrong?

FWIW, my code reported that, in the same 2600 test cases, 2560 test cases
resulted in the expected results (strtotime() reporting a valid value for
valid time, or reporting false for an invalid time), and 40 anomalous results
(strtotime() gave a valid value for an invalid time, or returned false for a
valid time).

Perhaps you didn't read or understand the purpose of my code?

Lew Pitcher

unread,

Oct 22, 2015, 10:48:10 AM10/22/15

to

On Thursday October 22 2015 10:43, in comp.lang.php, "Lew Pitcher"

I cleaned up your code's output and noticed
1896 failed
1897 failed
1898 failed
1899 failed
2060 failed
2061 failed
2062 failed
2063 failed
2064 failed
2065 failed

Hmmmm..... what happened to 1960 through 1999? Your code seems to think that
these are valid timestamps, as it *DID NOT* mark them as failures (and
counted them in the "$success" count.

Lew Pitcher

unread,

Oct 22, 2015, 11:07:09 AM10/22/15

to

On Thursday October 22 2015 05:12, in comp.lang.php, "Thomas 'PointedEars'

Lahn" <Point...@web.de> wrote:

> Lew Pitcher wrote:
>
>> […] "Richard Yates" […] wrote:
>>> On 20 Oct 2015 19:00:19 GMT, Derek Turner <frd...@suremail.je> wrote:
>>>> On Tue, 20 Oct 2015 18:57:34 +0000, Derek Turner wrote:
>>>>> Is there a quick and dirty way to check that
>>>>>
>>>>> substr($string, 0 ,3) is a valid military time, ie. 0000-2359?
>>>> sorry, that should, of course, read ($string, 0, 4)
>>>
>>> This seems to work, but I did not test all cases:
>>>
>>> echo (strtotime($time)) ? 'Pass' : 'Fail';
>>
>> PHP Version 5.4.45
>>
>> I tried all integer test cases between 0000 and 2599, and found that this
>> test seems to fail on the range "1960" to "1999". On the off chance that
>> the strtotime() call interpreted its argument as a date, […]
>
> Both of you are overthinking the problem. Compared to this, a solution
> based on string comparison (left as an exercise for the reader) is a one-or-
> two-liner (after all, the request said “quick and dirty”).

Nope. Not overthinking. Just testing strtotime().
And, if you are thinking of using a regex, you know what they say about
regular expressions:
Some people, when confronted with a problem, think "I know, I'll use regular
expressions." Now they have two problems.

My preferred solution would be the single line in my test code:

$expect = ((floor($ts/100) <= 24) && ($ts % 100 < 60)) ? 'Pass' : 'Fail';

which tests the hour for validity (00 through 24) and the minute for validity
(00 through 59).

Thomas 'PointedEars' Lahn

unread,

Oct 22, 2015, 11:18:49 AM10/22/15

to

Lew Pitcher wrote:

> On Thursday October 22 2015 05:12, in comp.lang.php, "Thomas 'PointedEars'
> Lahn" <Point...@web.de> wrote:

It’s attribution line, not attribution novel.

>> Lew Pitcher wrote:
>>> […] "Richard Yates" […] wrote:
>>>> On 20 Oct 2015 19:00:19 GMT, Derek Turner <frd...@suremail.je> wrote:
>>>>> On Tue, 20 Oct 2015 18:57:34 +0000, Derek Turner wrote:
>>>>>> Is there a quick and dirty way to check that
>>>>>>
>>>>>> substr($string, 0 ,3) is a valid military time, ie. 0000-2359?
>>>>> sorry, that should, of course, read ($string, 0, 4)
>>>> This seems to work, but I did not test all cases:
>>>>
>>>> echo (strtotime($time)) ? 'Pass' : 'Fail';
>>> PHP Version 5.4.45
>>>
>>> I tried all integer test cases between 0000 and 2599, and found that
>>> this test seems to fail on the range "1960" to "1999". On the off chance
>>> that the strtotime() call interpreted its argument as a date, […]
>> Both of you are overthinking the problem. Compared to this, a solution
>> based on string comparison (left as an exercise for the reader) is a

^^^^^^^^^^^^^^^^^^^^^^^^^^

>> one-or- two-liner (after all, the request said “quick and dirty”).
>
> Nope. Not overthinking. Just testing strtotime().

Given that strtotime() is error-prone overkill *here* (one could see that
before doing any tests, just by reading the manual carefully), there is not
much point in testing it *here*.

> And, if you are thinking of using a regex, […]

Iff. I did not. But I found it necessary to point out that the solution
presented using regular expressions was too complicated and too inefficient
even for that approach.

> […]

Ex falso quodlibet.

> My preferred solution would be the single line in my test code:
> $expect = ((floor($ts/100) <= 24) && ($ts % 100 < 60)) ? 'Pass' :
> 'Fail';
> which tests the hour for validity (00 through 24) and the minute for
> validity (00 through 59).

You are very close to my actual suggestion. Considering the cost of the
floor() call and “%” operation (in general: any floating-point operation)
will lead you to the probably most simple, efficient solution.

Thomas 'PointedEars' Lahn

unread,

Oct 22, 2015, 11:20:48 AM10/22/15

to

Lew Pitcher wrote:

> But, in the military clock, there are 25 hours (00 through 24) and 60

> minutes per hour (00 through 59). […]

Then the test code I posted has to be modified slightly.

Jerry Stuckle

unread,

Oct 22, 2015, 12:19:33 PM10/22/15

to

I read and understood the purpose of your code. Then I wrote my own
code and ran it under PHP 5.6.13 (64 bit). It came out with 1500
successes and 1100 failures, as expected.

The problem was I don't have access to Usenet from that machine, so I
ran the code on a Windows machine which is currently running PHP 5.4.14
(again, 64 bit) where if failed. The problem is I didn't as much
attention to the output that I should have.

So it looks like a bug which has been fixed in PHP 5.6.13 (at least on
Linux).

Jerry Stuckle

unread,

Oct 22, 2015, 1:17:57 PM10/22/15

to

On 10/21/2015 4:12 PM, Lew Pitcher wrote:

> <?php
> $success = 0;
> $failed = 0;
>
> for ($ts = 0; $ts < 2600; ++$ts)
> {
> $time = sprintf("t%04.4u",$ts);
> $expect = ((floor($ts/100) <= 24) && ($ts % 100 < 60)) ? 'Pass' : 'Fail';
> $result = (strtotime($time)) ? 'Pass' : 'Fail';
> $matched = ($expect == $result) ? 'Success' : 'Failed';
> printf("<li>%s - %s: expected %s, got %s</li>\n",
> $time,$matched,$expect,$result);
> if ($matched == 'Success')
> ++$success;
> else
> ++$failed;
> }
> ?>
> </ul>
> <?php
> printf("%u Successful cases, %u failures\n",$success,$failed);
> ?>

And BTW - changing your code to:

$time = sprintf("t%02.2u:%02.2u",$ts/100, $ts%100);

Also prints the correct result - it tells strtotime() that this is a
time, and not something else. Just the number by itself with no
punctuation marks makes strtotime() guess as to what it represents.

Peter H. Coffin

unread,

Oct 22, 2015, 4:55:16 PM10/22/15

to

On Thu, 22 Oct 2015 10:43:58 -0400, Lew Pitcher wrote:
>
> But, in the military clock, there are 25 hours (00 through 24) and 60 minutes
> per hour (00 through 59). Thus, in 2600 test cases, ranging sequentially from
> 0000 through 2599, there should be 25x60 successes 25 hours, with 60 values
> inside of the 00-59 range). That means 1500 successes in 2600 test cases.

I am pretty sure that this is not the case. I have never seen "24:xx". I
have, however, seen "03:60". Leapseconds are rare, but happen often
enough that code looking for valid times should account for it.

--
16 megs in a '95 box! Yo Ho Ho and a battle of RAM!

Thomas 'PointedEars' Lahn

unread,

Oct 22, 2015, 5:08:35 PM10/22/15

to

Peter H. Coffin wrote:

> On Thu, 22 Oct 2015 10:43:58 -0400, Lew Pitcher wrote:
>> But, in the military clock, there are 25 hours (00 through 24) and 60
>> minutes per hour (00 through 59). Thus, in 2600 test cases, ranging
>> sequentially from 0000 through 2599, there should be 25x60 successes 25
>> hours, with 60 values inside of the 00-59 range). That means 1500
>> successes in 2600 test cases.
>
> I am pretty sure that this is not the case. I have never seen "24:xx".

I have never been in the military, and hopefully never will be, but I find
it reasonable that they would adopt the timekeeping standard of having days
from 00:00:00.000 to 24:00:00.000 inclusive.

> I have, however, seen "03:60". Leapseconds are rare, but happen often
> enough that code looking for valid times should account for it.

ACK.

Lew Pitcher

unread,

Oct 22, 2015, 5:13:28 PM10/22/15

to

On Thursday October 22 2015 16:32, in comp.lang.php, "Peter H. Coffin"

<hel...@ninehells.com> wrote:

> On Thu, 22 Oct 2015 10:43:58 -0400, Lew Pitcher wrote:
>>
>> But, in the military clock, there are 25 hours (00 through 24) and 60
>> minutes per hour (00 through 59). Thus, in 2600 test cases, ranging
>> sequentially from 0000 through 2599, there should be 25x60 successes 25
>> hours, with 60 values inside of the 00-59 range). That means 1500 successes
>> in 2600 test cases.
>
> I am pretty sure that this is not the case. I have never seen "24:xx".

Agreed that 2400 through 2459 are unusual cases. Wikipedia (always the
authoritative source :-) says
Times after 24:00
Time-of-day notations beyond 24:00 (such as 24:01 or 25:59 instead of
00:01 or 01:59) are not commonly used and not covered by the relevant
standards. However, they have been used occasionally in some special
contexts in the UK, Japan, Hong Kong and China where business hours extend
beyond midnight, such as broadcast television production and scheduling.
They also appear in some public transport applications, such as Google's
General Transit Feed Specification file format and some ticketing systems
(e.g. in Copenhagen). This usage prevents a time period reported without
dates from appearing to end before its beginning, e.g. 21:00–01:00.
I've sometimes had to use this timestamp range in applications, so I included
it in my test case. It looks like PHP's strtotime() function considers it to
be a valid timestamp, no matter what my (or your) opinion of it is.

> I have, however, seen "03:60". Leapseconds are rare, but happen often
> enough that code looking for valid times should account for it.

Maybe so. To me, 03:60 is as unusual as 24:30. PHP's strtotime(), however,
considers 03:60 (in any format) as "not a time value". So, perhaps
strtotime() isn't as reliable a validator for "military time" as it might
have been.

Gordon Burditt

unread,

Oct 22, 2015, 6:40:29 PM10/22/15

to

> But, in the military clock, there are 25 hours (00 through 24) and 60 minutes
> per hour (00 through 59).

Could you post a reference for this statement? Most references
only refer to 0000 - 2359 as valid times, making no reference to
2400. A few refer to 2400 as being for "end of the day" when used
in a time range. (e.g. "This bar is open 0800 - 2400") Leap seconds
don't affect this, as seconds aren't represented; there are no leap
minutes until a big asteroid hits and makes a big change in the
Earth's rotation.

I can see a use for 2400 but when is 2401 a valid military time?
Much less 2459 or 2559 (unless you're only using these as test cases
to verify detection of bad times)?

(I also see a claim on www.leatherneck.com under a thread "what is
military time for midnight", posted to by ex-Marines (or possibly
current Marines), that 0000 is meaningless and the correct time is
2400. A similar claim was made for compass readings: 0 is meaningless
and 360 is North, possibly because a particular digital compass reads
0 until it acquires a reading.)

> Thus, in 2600 test cases, ranging sequentially from
> 0000 through 2599, there should be 25x60 successes 25 hours, with 60 values
> inside of the 00-59 range). That means 1500 successes in 2600 test cases.
>
> But, your logic came up with 1540 successes. Apparently, your code got
> 40 "wrong" timestamps wrong. Now, Jerry, *which* 40 were wrong?

I think the cases really need to be divided into 4 groups, such as
correctly flagged successes, correctly flagged failures, false
positives, and false negatives. Otherwise an equal number of false
positives and false negatives don't show up in the totals.

Gordon Burditt

unread,

Oct 22, 2015, 7:21:56 PM10/22/15

to

>> But, in the military clock, there are 25 hours (00 through 24) and 60 minutes
>> per hour (00 through 59). Thus, in 2600 test cases, ranging sequentially from
>> 0000 through 2599, there should be 25x60 successes 25 hours, with 60 values
>> inside of the 00-59 range). That means 1500 successes in 2600 test cases.
>
> I am pretty sure that this is not the case. I have never seen "24:xx". I
> have, however, seen "03:60".

What does that mean? Leap *minutes*? Where would you see that?
Someplace other than Earth?

> Leapseconds are rare, but happen often
> enough that code looking for valid times should account for it.

A leap second would occur at 23:59:60 UTC. The hour would be
different in other time zones. Military time does not generally
include seconds, so you don't see anything different when a leap
second happen..

Jerry Stuckle

unread,

Oct 22, 2015, 8:19:34 PM10/22/15

to

On 10/22/2015 5:08 PM, Thomas 'Pointed Head' Lahn wrote:
> Peter H. Coffin wrote:
>
>> On Thu, 22 Oct 2015 10:43:58 -0400, Lew Pitcher wrote:
>>> But, in the military clock, there are 25 hours (00 through 24) and 60
>>> minutes per hour (00 through 59). Thus, in 2600 test cases, ranging
>>> sequentially from 0000 through 2599, there should be 25x60 successes 25
>>> hours, with 60 values inside of the 00-59 range). That means 1500
>>> successes in 2600 test cases.
>>
>> I am pretty sure that this is not the case. I have never seen "24:xx".
>
> I have never been in the military, and hopefully never will be, but I find
> it reasonable that they would adopt the timekeeping standard of having days
> from 00:00:00.000 to 24:00:00.000 inclusive.
>

How fortunate for the military.

Jerry Stuckle

unread,

Oct 22, 2015, 8:21:13 PM10/22/15

to

You think Wikipedia is authoritative? ROFLMAO! All that is is a
collection of personal opinions. I've seen more incorrect entries on
Wikipedia than I can count.

>> I have, however, seen "03:60". Leapseconds are rare, but happen often
>> enough that code looking for valid times should account for it.
>
> Maybe so. To me, 03:60 is as unusual as 24:30. PHP's strtotime(), however,
> considers 03:60 (in any format) as "not a time value". So, perhaps
> strtotime() isn't as reliable a validator for "military time" as it might
> have been.
>
>

Which is also not authoritative. Just the opinion of one programmer.

Jerry Stuckle

unread,

Oct 22, 2015, 8:22:16 PM10/22/15

to

On 10/22/2015 5:57 PM, Tim Streater wrote:
> In article <RjcWx.106396$DK7....@fx02.iad>, Lew Pitcher

> <lew.p...@digitalfreehold.ca> wrote:
>
>> On Thursday October 22 2015 16:32, in comp.lang.php, "Peter H. Coffin"
>> <hel...@ninehells.com> wrote:
>>
>>> On Thu, 22 Oct 2015 10:43:58 -0400, Lew Pitcher wrote:
>>>>
>>>> But, in the military clock, there are 25 hours (00 through 24) and 60
>>>> minutes per hour (00 through 59). Thus, in 2600 test cases, ranging
>>>> sequentially from 0000 through 2599, there should be 25x60 successes 25
>>>> hours, with 60 values inside of the 00-59 range). That means 1500
>>>> successes
>>>> in 2600 test cases.
>>>
>>> I am pretty sure that this is not the case. I have never seen "24:xx".
>>
>> Agreed that 2400 through 2459 are unusual cases. Wikipedia (always the
>> authoritative source :-) says
>> Times after 24:00
>> Time-of-day notations beyond 24:00 (such as 24:01 or 25:59 instead of
>> 00:01 or 01:59) are not commonly used and not covered by the relevant
>> standards. However, they have been used occasionally in some special

>> contexts in the UK, ...
>
> I've never heard of this in any context. Mind you "military time" is
> also generally unknown here; I've always assumed it to be a peculiarity
> of the US military.
>

Military time is common to militaries throughout the world - not just
the U.S.

Jerry Stuckle

unread,

Oct 22, 2015, 8:23:43 PM10/22/15

to

Military time definitely includes seconds.. And in many cases, even
hundredths of seconds or even more specific.

Lew Pitcher

unread,

Oct 22, 2015, 8:39:14 PM10/22/15

to

On Thursday October 22 2015 20:21, in comp.lang.php, "Jerry Stuckle"

<jstu...@attglobal.net> wrote:

> On 10/22/2015 5:13 PM, Lew Pitcher wrote:
>> On Thursday October 22 2015 16:32, in comp.lang.php, "Peter H. Coffin"
>> <hel...@ninehells.com> wrote:
>>
>>> On Thu, 22 Oct 2015 10:43:58 -0400, Lew Pitcher wrote:
>>>>
>>>> But, in the military clock, there are 25 hours (00 through 24) and 60
>>>> minutes per hour (00 through 59). Thus, in 2600 test cases, ranging
>>>> sequentially from 0000 through 2599, there should be 25x60 successes 25
>>>> hours, with 60 values inside of the 00-59 range). That means 1500
>>>> successes in 2600 test cases.
>>>
>>> I am pretty sure that this is not the case. I have never seen "24:xx".
>>
>> Agreed that 2400 through 2459 are unusual cases. Wikipedia (always the
>> authoritative source :-) says

[snip]

> You think Wikipedia is authoritative? ROFLMAO!

You missed the smiley.

/Of course/ I don't think that Wikipedia is authoritative. It is /far/ from
authoritative. But, it'll do in a pinch.

[snip]

Jerry Stuckle

unread,

Oct 22, 2015, 8:47:13 PM10/22/15

to

On 10/22/2015 8:38 PM, Lew Pitcher wrote:
> On Thursday October 22 2015 20:21, in comp.lang.php, "Jerry Stuckle"
> <jstu...@attglobal.net> wrote:
>
>> On 10/22/2015 5:13 PM, Lew Pitcher wrote:
>>> On Thursday October 22 2015 16:32, in comp.lang.php, "Peter H. Coffin"
>>> <hel...@ninehells.com> wrote:
>>>
>>>> On Thu, 22 Oct 2015 10:43:58 -0400, Lew Pitcher wrote:
>>>>>
>>>>> But, in the military clock, there are 25 hours (00 through 24) and 60
>>>>> minutes per hour (00 through 59). Thus, in 2600 test cases, ranging
>>>>> sequentially from 0000 through 2599, there should be 25x60 successes 25
>>>>> hours, with 60 values inside of the 00-59 range). That means 1500
>>>>> successes in 2600 test cases.
>>>>
>>>> I am pretty sure that this is not the case. I have never seen "24:xx".
>>>
>>> Agreed that 2400 through 2459 are unusual cases. Wikipedia (always the
>>> authoritative source :-) says
> [snip]
>> You think Wikipedia is authoritative? ROFLMAO!
>
> You missed the smiley.
>

Not really.

> /Of course/ I don't think that Wikipedia is authoritative. It is /far/ from
> authoritative. But, it'll do in a pinch.
>
> [snip]
>

It doesn't even do "in a pinch"...

Matthew Carter

unread,

Oct 22, 2015, 10:07:38 PM10/22/15

to

Jerry Stuckle <jstu...@attglobal.net> writes:

> On 10/22/2015 5:08 PM, Thomas 'Pointed Head' Lahn wrote:
>> Peter H. Coffin wrote:
>>
>>> On Thu, 22 Oct 2015 10:43:58 -0400, Lew Pitcher wrote:
>>>> But, in the military clock, there are 25 hours (00 through 24) and 60
>>>> minutes per hour (00 through 59). Thus, in 2600 test cases, ranging
>>>> sequentially from 0000 through 2599, there should be 25x60 successes 25
>>>> hours, with 60 values inside of the 00-59 range). That means 1500
>>>> successes in 2600 test cases.
>>>
>>> I am pretty sure that this is not the case. I have never seen "24:xx".
>>
>> I have never been in the military, and hopefully never will be, but I find
>> it reasonable that they would adopt the timekeeping standard of having days
>> from 00:00:00.000 to 24:00:00.000 inclusive.
>>
>
> How fortunate for the military.

It's considered a science vessel, despite a full array of armaments.

--
Matthew Carter (m...@ahungry.com)
http://ahungry.com

Beauregard T. Shagnasty

unread,

Oct 22, 2015, 10:29:05 PM10/22/15

to

Thomas 'PointedHead' Lahn wrote:

> I have never been in the military,

..and so don't know about their time.

> and hopefully never will be,

Good. We don't need you.

> but I
> find it reasonable that they would adopt the timekeeping standard of
> having days from 00:00:00.000 to 24:00:00.000 inclusive.

00:00:00.000 to 24:00:00.000 are functionally the same, but "24" is never
used. The day ends at 23:59:59.999 and then ticks over back to
00:00:00.000.

--
-bts
-This space for rent, but the price is high

Jerry Stuckle

unread,

Oct 23, 2015, 9:32:37 AM10/23/15

to

On 10/23/2015 4:19 AM, Tim Streater wrote:
> In article <n0bufg$kmh$3...@dont-email.me>, Jerry Stuckle

> I'll believe you, thousands wouldn't, as my old Dad used to say. I
> doubt if any civilian here would have heard of it, and the phrase never
> appears in the media, either.
>

Well, it's used by amateur radio operators and short wave listeners
around the world, not to mention the TV and radio stations themselves,
internally. It's also used by astronomers, physicists and other
scientists. UTC, for instance, is almost always specified in 24 hour
format. While more commonly called "24 hour time", people who use it
generally understand the term "military time".

And BTW - it does go from 00:00 to 24:59:59. 24:00:00 is generally
considered the end of the day and 00:00:00 the beginning of the day, but
24:00:00 - 24:59:59 is sometimes used when something goes just past the
end of the day. Less common now than it was back in the 60's, but you
still see it occasionally.

Jerry Stuckle

unread,

Oct 23, 2015, 11:11:59 AM10/23/15

to

On 10/23/2015 10:43 AM, Tim Streater wrote:
> In article <n0dcpa$uns$1...@dont-email.me>, Jerry Stuckle

> <jstu...@attglobal.net> wrote:
>
>> On 10/23/2015 4:19 AM, Tim Streater wrote:
>
>>> I'll believe you, thousands wouldn't, as my old Dad used to say. I
>>> doubt if any civilian here would have heard of it, and the phrase never
>>> appears in the media, either.
>>
>> Well, it's used by amateur radio operators and short wave listeners
>> around the world, not to mention the TV and radio stations themselves,
>> internally. It's also used by astronomers, physicists and other
>> scientists. UTC, for instance, is almost always specified in 24 hour
>> format.
>

> Plenty of people use the 24-hour clock, it's used also by railways, and
> it's never referred to as anything other than the 24-hour clock.

>
>> While more commonly called "24 hour time", people who use it
>> generally understand the term "military time".
>

> Unlikely here.
>

You haven't been watching enough war movies :)

Gordon Burditt

unread,

Oct 23, 2015, 1:36:35 PM10/23/15

to

If you're going to use times past 2400 for time ranges, what limits
the range? For example, it's perfectly reasonable to say "a sleep
study at the sleep clinic typically runs from 2100 to 2930". (I'm
thinking of a specific clinic that has those hours.) It makes just
as much sense as "the bar is open from 0800 to 2430".

I'm sure I could come up with some excuse for needing 12733 as a
time (say, in the arrival time of an oil tanker or cruise ship
relative to the departure time). How do I know that 3506400 (the
length of a presidential term in the USA, give or take for century
leap years and leap seconds) is not also valid?

I note that the Wikipedia article says that 2559 is as valid
as 2459. Why do you think one is valid and the other is not?

> Well, it's used by amateur radio operators and short wave listeners
> around the world, not to mention the TV and radio stations themselves,
> internally.

Do amateur radio operators and short wave listeners use times in
the range 2401 - 2459, but *NOT* anything beyond that? Why?

> It's also used by astronomers, physicists and other
> scientists.

Do they use times 2401 thru 2459, and *NOT* anything beyond that?
For what? The duration of lunar eclipses? I think they last way
longer than an hour.

> UTC, for instance, is almost always specified in 24 hour
> format. While more commonly called "24 hour time", people who use it
> generally understand the term "military time".

I don't think most people who use 24 hour time because they want 24
hour time, not because the military says so, expect it to have
25 hours. Even 0000 vs. 2400 is somewhat controversial.

> And BTW - it does go from 00:00 to 24:59:59. 24:00:00 is generally
> considered the end of the day and 00:00:00 the beginning of the day, but
> 24:00:00 - 24:59:59 is sometimes used when something goes just past the
> end of the day. Less common now than it was back in the 60's, but you

You do like proof by repetitive assertion, don't you?

Authoritative cite, please, that states that 2459 is a valid time
and 2500 isn't. Preferably in a standard or military training
manual (any military, although it would help if it were in a language
that someone (Google?) could translate to English). I note that
the Wikipedia article quoted in this thread says that 2459 and 2559
are equally valid (although Wikipedia is rarely considered authoritative
for anything) and that article claims that such use is not listed
in standards.

> still see it occasionally.

I bet you still see @!00 (typed on a computer keyboard with a USA
layout) or 22300 occasionally. It's called a typographical error.

I'm hoping to get an answer better than "It's used by Jerry Stuckle in
his schedule to feed his goats."

Jerry Stuckle

unread,

Oct 23, 2015, 1:40:32 PM10/23/15

to

On 10/23/2015 1:36 PM, Gordon Burditt wrote:
> If you're going to use times past 2400 for time ranges, what limits
> the range? For example, it's perfectly reasonable to say "a sleep
> study at the sleep clinic typically runs from 2100 to 2930". (I'm
> thinking of a specific clinic that has those hours.) It makes just
> as much sense as "the bar is open from 0800 to 2430".
>
> I'm sure I could come up with some excuse for needing 12733 as a
> time (say, in the arrival time of an oil tanker or cruise ship
> relative to the departure time). How do I know that 3506400 (the
> length of a presidential term in the USA, give or take for century
> leap years and leap seconds) is not also valid?
>
> I note that the Wikipedia article says that 2559 is as valid
> as 2459. Why do you think one is valid and the other is not?
>

I didn't say 2559 wasn't valid. All I said was the times from 2400 to
2459 are commonly used to indicate the same day.

The rest of your post is just plain argument and personal insults. Just
what you expect from a troll.

Norman Peelman

unread,

Oct 23, 2015, 10:44:04 PM10/23/15

to

It is common around the world (maybe just not to you) and isn't peculiar
at all. ie: there's only one 15:00 a day, there are however two 3:00
o'clocks. If I told you to meet me in the parking lot at 3, what time
would you show up, AM or PM?

>
> Well, it's used by amateur radio operators and short wave listeners
> around the world, not to mention the TV and radio stations themselves,
> internally. It's also used by astronomers, physicists and other
> scientists. UTC, for instance, is almost always specified in 24 hour
> format. While more commonly called "24 hour time", people who use it
> generally understand the term "military time".
>
> And BTW - it does go from 00:00 to 24:59:59. 24:00:00 is generally
> considered the end of the day and 00:00:00 the beginning of the day, but
> 24:00:00 - 24:59:59 is sometimes used when something goes just past the
> end of the day. Less common now than it was back in the 60's, but you
> still see it occasionally.
>

I'm ex-NAVY and have never seen, used or heard of times beyond 24:00.
What time is 27:45? It serves as an attempt to represent a dual role,
time and duration. In the NAVY, if we had the last watch of the day we
referred to it as the 20:00 - 24:00 ("twenty to twenty-four"), the first
watch of the day was 00:00 - 04:00 (we called this "balls to 4".) I'll
give another great NAVY example; The Bars close at 02:00 (not 26:00).

Derek Turner

unread,

Oct 24, 2015, 7:41:45 AM10/24/15

to

On Fri, 23 Oct 2015 22:44:15 -0400, Norman Peelman wrote:

> It is common around the world (maybe just not to you) and isn't peculiar
> at all. ie: there's only one 15:00 a day, there are however two 3:00
> o'clocks. If I told you to meet me in the parking lot at 3, what time
> would you show up, AM or PM?

I think we all understand that. Just to be clear when I (the OP) used the
term 'military time' I meant to indicate that NO PUNCTUATION/SEPARATOR
was being used e.g. 0900, pronounced oh-nine-hundred as opposed to 9.30
09.30 or 09:30. This is the form used by the military (world-wide AFAIK)
and at sea by radio operators and in Nautical Almanacs (tide-tables) etc.

Hope this helps.

Norman Peelman

unread,

Oct 24, 2015, 3:15:31 PM10/24/15

to

Correct, when referenced that way those in the know assume the 24 hour
clock is being used.

Arno Welzel

unread,

Oct 27, 2015, 9:10:24 AM10/27/15

to

Jerry Stuckle schrieb am 2015-10-22 um 16:23:

> On 10/22/2015 9:11 AM, Thomas 'PointedEars' Lahn wrote:
[...]
>> Avoid ending PHP files with that; you may be accidentally outputting
>> trailing whitespace otherwise.
>>
>
> Another stoopid comment by the troll.

JFTR: PHP scripts can not only output text and additional white space at
the end may invalidate the output. Omitting the closing tag does not
cause any harm but will avoid this for sure.

--
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de
http://fahrradzukunft.de

Jerry Stuckle

unread,

Oct 27, 2015, 9:25:22 AM10/27/15

to

On 10/27/2015 9:10 AM, Arno Welzel wrote:
> Jerry Stuckle schrieb am 2015-10-22 um 16:23:
>
>> On 10/22/2015 9:11 AM, Thomas 'PointedEars' Lahn wrote:
> [...]
>>> Avoid ending PHP files with that; you may be accidentally outputting
>>> trailing whitespace otherwise.
>>>
>>
>> Another stoopid comment by the troll.
>
> JFTR: PHP scripts can not only output text and additional white space at
> the end may invalidate the output. Omitting the closing tag does not
> cause any harm but will avoid this for sure.
>
>

Good programming will avoid this problem, for sure. Crappy programmers
need crappy workarounds.

Omitting a closing tag will cause harm if someone tries to add html at
the end of the page.

Jørn Andersen

unread,

Oct 27, 2015, 10:19:23 AM10/27/15

to

On Tue, 27 Oct 2015 09:25:31 -0400, Jerry Stuckle
<jstu...@attglobal.net> wrote:

>On 10/27/2015 9:10 AM, Arno Welzel wrote:

<snip>

>> JFTR: PHP scripts can not only output text and additional white space at
>> the end may invalidate the output. Omitting the closing tag does not
>> cause any harm but will avoid this for sure.

>Good programming will avoid this problem, for sure. Crappy programmers
>need crappy workarounds.

php.net recommends not using the PHP closing tag “if a file is pure
PHP code”.
http://php.net/manual/en/language.basic-syntax.phptags.php

>Omitting a closing tag will cause harm if someone tries to add html at
>the end of the page.

--

Jørn Andersen
http://socialister.dk
http://marxisme.dk

Jerry Stuckle

unread,

Oct 27, 2015, 10:41:44 AM10/27/15

to

First of all, that is a big "if". Second, this is an opinion of one (or
a small group of) programmers which violates good coding practices which
have worked for decades. But then I have never been that impressed with
the programmers there.

Thomas 'PointedEars' Lahn

unread,

Oct 27, 2015, 5:59:06 PM10/27/15

to

J�rn Andersen wrote:
^^^^
The characters in your From header are not properly encoded, so they end up
as garbage with readers unless their newsreaders make a good guess. The
same may be true of Subject header field values posted by you, which can
effectively destroy threads you participate in (depending on the previous
Subject, if any, and your choice of characters if it is an OP).

Please either do not post non-ASCII-characters there, use a server that can
fix this on the fly, or try upgrading Forté Agent (the current version is
8.0, you are using 6.0.x).

> […] Jerry Stuckle […] wrote:
>> On 10/27/2015 9:10 AM, Arno Welzel wrote:
> <snip>
>>> JFTR: PHP scripts can not only output text and additional white space at
>>> the end may invalidate the output. Omitting the closing tag does not
>>> cause any harm but will avoid this for sure.
>> Good programming will avoid this problem, for sure. Crappy programmers
>> need crappy workarounds.
>
> php.net recommends not using the PHP closing tag “if a file is pure
> PHP code”.
> http://php.net/manual/en/language.basic-syntax.phptags.php

So do the PEAR Coding Standards since quite a while, and more recently PSR-2
which have been developed and are observed by major (PHP) players such as
CakePHP, Composer, Contao, Doctrine, Drupal, Joomla, PEAR, phpBB,
phpDocumentor, SugarCRM, Symfony, and Zend Framework 2. (AISB. But Jerry
Stuckle is always right. You will be hated. Resistance is futile :->)

<http://www.php-fig.org/psr/psr-2/>
<http://www.php-fig.org/members/>

But in fact, it is best to *never* write the “?>” at the *end* of a file
that is parsed by PHP because where there is not only pure PHP code (like in
a template) you *also* do not want to output whitespace content
accidentally. (And this can happen easily. For example, unless you tell it
not to, Vim always appends newline on save.) An end marker there is quite
simply an *unnecessary* cause of problems, and nothing is gained by writing
it. PHP parsing will end automatically anyway when EOF is reached, and any
standalone whitespace is ignored in parse mode.

Matthew Carter

unread,

Oct 27, 2015, 11:03:52 PM10/27/15

to

Jerry Stuckle <jstu...@attglobal.net> writes:

> On 10/27/2015 10:19 AM, J�rn Andersen wrote:
>> On Tue, 27 Oct 2015 09:25:31 -0400, Jerry Stuckle
>> <jstu...@attglobal.net> wrote:
>>
>>> On 10/27/2015 9:10 AM, Arno Welzel wrote:
>> <snip>
>>>> JFTR: PHP scripts can not only output text and additional white space at
>>>> the end may invalidate the output. Omitting the closing tag does not
>>>> cause any harm but will avoid this for sure.
>>
>>> Good programming will avoid this problem, for sure. Crappy programmers
>>> need crappy workarounds.
>>
>> php.net recommends not using the PHP closing tag “if a file is pure
>> PHP code”.
>> http://php.net/manual/en/language.basic-syntax.phptags.php
>>
>>> Omitting a closing tag will cause harm if someone tries to add html at
>>> the end of the page.
>>
>>
>
> First of all, that is a big "if". Second, this is an opinion of one (or
> a small group of) programmers which violates good coding practices which
> have worked for decades. But then I have never been that impressed with
> the programmers there.

PSR recommends that definitions (classes/functions) and code producing
side effects be in separate files anyways, so I see no issue with
omitting a closing tag in definition files (as no HTML should be
randomly added to the end anyways) and detecting that your HTML is
failing to render due to being within an unclosed PHP tag is easier to
debug than a closed tag with whitespace hidden afterwards.

Jerry Stuckle

unread,

Oct 27, 2015, 11:29:21 PM10/27/15

to

YOU don't see any problem. Good programmers do.

Just wait until you run into a problem because of it. Your tune will
change. And I'm not the only one who feels this way.

Erwin Moller

unread,

Oct 29, 2015, 5:08:41 AM10/29/15

to

Seconded.
Always use the closing tag.

<opinionated>
If you get into trouble because you produce output after the closing
tag, get another job.
If that is over your head, you should change jobs, not the programming
language (or usage of it).
It isn't that hard.
This advice from php.net is ridiculous.

This reminds me a lot of the curly bracket in conditional statements.
Some seem to think omitting them is alright for single statements.
It is, of course, not alright to omit them.
</opinionated>

Regards,
Erwin Moller

--
"That which can be asserted without evidence, can be dismissed without
evidence."
-- Christopher Hitchens

Matthew Carter

unread,

Oct 29, 2015, 9:44:42 PM10/29/15

to

Other than a feeling of self righteousness, what is gained again?

Tell me, in these two sample files, which is easier to debug if the
aforementioned use cases occurred that cause an error when the file is
included by another file making use of header responses:

------------------File One (no closing tag, misplaced HTML)-----------
<?php

function add($a, $b) {
return $a + $b;
}

<h1>This is my great page of addition!</h1>

------------------File Two (closing tag, extra space)-----------------
<?php

function add($a, $b) {
return $a + $b;
}

?>

Assuming both were included/required in another file, which one would
the majority of programmers have an easier time pinpointing the error
with? (hint: the one where the PHP error reporting would tell you
exactly where the faulty HTML was originating, NOT the file that was
outputting some whitespace before a header call - that error would send
you to the header() call line, not the bad file with trailing space).

There have been 0 good reasons for including a closing tag (it's just too
bad we can't actually have a '.phpdef' file type or something that
simulates a 100% PHP only file, without dropping in and out of tags and
just avoids the use of the <?php ?> nonsense entirely).

Jerry Stuckle

unread,

Oct 29, 2015, 10:35:27 PM10/29/15

to

Proper coding techniques and it wouldn't happen in the first place.

But to answer your question - the problem is your test can cause a fatal
error, potentially displaying internal information to a user. This
information could be used to hack the system.

But I know you will dismiss any reason given, so go ahead and make a
fool of yourself. You've obviously never worked on a multi-programmer
project with coding conventions.

Arno Welzel

unread,

Oct 30, 2015, 3:01:30 PM10/30/15

to

Jerry Stuckle schrieb am 2015-10-27 um 14:25:

> On 10/27/2015 9:10 AM, Arno Welzel wrote:
>> Jerry Stuckle schrieb am 2015-10-22 um 16:23:
>>
>>> On 10/22/2015 9:11 AM, Thomas 'PointedEars' Lahn wrote:
>> [...]
>>>> Avoid ending PHP files with that; you may be accidentally outputting
>>>> trailing whitespace otherwise.
>>>>
>>>
>>> Another stoopid comment by the troll.
>>
>> JFTR: PHP scripts can not only output text and additional white space at
>> the end may invalidate the output. Omitting the closing tag does not
>> cause any harm but will avoid this for sure.
>>
>>
>
> Good programming will avoid this problem, for sure. Crappy programmers
> need crappy workarounds.

It's not a "crappy workaround".

If PHP would *require* a closing tag at the end of a script it would
cause a runtime error when omitting it. But it does not - for good reasons.

Maybe you believe the official PHP documentation more than me:

<http://php.net/manual/en/language.basic-syntax.phptags.php>

Cite:

"If a file is pure PHP code, it is preferable to omit the PHP closing
tag at the end of the file. This prevents accidental whitespace or new
lines being added after the PHP closing tag, which may cause unwanted
effects because PHP will start output buffering when there is no
intention from the programmer to send any output at that point in the
script."

> Omitting a closing tag will cause harm if someone tries to add html at
> the end of the page.

Well - when changing a script one should do this carefully anyway and
not just add HTML without looking at the code. Or do you just blindly
add HTML to production code and use it without testing?

Arno Welzel

unread,

Oct 30, 2015, 3:04:40 PM10/30/15

to

Jerry Stuckle schrieb am 2015-10-27 um 15:41:

> On 10/27/2015 10:19 AM, J�rn Andersen wrote:
>> On Tue, 27 Oct 2015 09:25:31 -0400, Jerry Stuckle
>> <jstu...@attglobal.net> wrote:
>>
>>> On 10/27/2015 9:10 AM, Arno Welzel wrote:
>> <snip>
>>>> JFTR: PHP scripts can not only output text and additional white space at
>>>> the end may invalidate the output. Omitting the closing tag does not
>>>> cause any harm but will avoid this for sure.
>>
>>> Good programming will avoid this problem, for sure. Crappy programmers
>>> need crappy workarounds.
>>
>> php.net recommends not using the PHP closing tag “if a file is pure
>> PHP code”.
>> http://php.net/manual/en/language.basic-syntax.phptags.php
>>
>>> Omitting a closing tag will cause harm if someone tries to add html at
>>> the end of the page.
>>
>>
>
> First of all, that is a big "if". Second, this is an opinion of one (or
> a small group of) programmers which violates good coding practices which
> have worked for decades. But then I have never been that impressed with
> the programmers there.

We all know that you are only impressed by yourself.

JFTR: PHP does not exist for "decades" - the first usable version 3.0 is
from 1997. Most other languages don't know the concept of "closing tags"
at all (C, C++, Java, Fortran, Cobol, Assembler, shell scripts for
sh/bash etc.). Therefore it can not be a "good coding practice" to add
closing tag to a script.

Arno Welzel

unread,

Oct 30, 2015, 3:08:40 PM10/30/15

to

Therefore one

1) will TEST stuff BEFORE it goes to the production system

2) configures the production system in a way that it will NEVER display
ANY error to the user

Do you really want to tell us you don't know that?

> But I know you will dismiss any reason given, so go ahead and make a
> fool of yourself. You've obviously never worked on a multi-programmer
> project with coding conventions.

And you seem to never have worked on real production systems. And yes -
omitting closing tags *can* be a coding convention within the team as well.

Jerry Stuckle

unread,

Oct 30, 2015, 4:21:51 PM10/30/15

to

Trolls like you need their hands held.

>> But I know you will dismiss any reason given, so go ahead and make a
>> fool of yourself. You've obviously never worked on a multi-programmer
>> project with coding conventions.
>
> And you seem to never have worked on real production systems. And yes -
> omitting closing tags *can* be a coding convention within the team as well.
>
>

You have no idea. I've worked on MUCH larger production systems than
you could ever think of. How about one with over 10,000 concurrent
users, for instance?

And yes, committing closing tags can be a coding convention - for trolls
and newbies. Good programmers close their tags.

Jerry Stuckle

unread,

Oct 30, 2015, 4:23:53 PM10/30/15

to

I sure am not impressed with you! You can't even read English. I
didn't say PHP existed for decades; I said the good programming
practices have existed for decades. And PHP is not only NOT the only
language with closing tags - it is far from the first language with
closing tags.

But trolls don't understand that. They're too full of themselves to learn.

Jerry Stuckle

unread,

Oct 30, 2015, 4:26:49 PM10/30/15

to

As I said - I don't think much of the "programmers" at PHP. I haven't
seen a lot of competence from most of them, and have seen a fair amount
of incompetence from several.

>> Omitting a closing tag will cause harm if someone tries to add html at
>> the end of the page.
>
> Well - when changing a script one should do this carefully anyway and
> not just add HTML without looking at the code. Or do you just blindly
> add HTML to production code and use it without testing?
>
>

Trolls being careful? ROFLMAO! But we know you only exist to raise
hell on usenet. You don't do any real programming.

Time for you to go back to washing dishes, Arno.

Thomas 'PointedEars' Lahn

unread,

Oct 30, 2015, 5:33:42 PM10/30/15

to

Matthew Carter wrote:

> There have been 0 good reasons for including a closing [PHP] tag

ACK.

> (it's just too bad we can't actually have a '.phpdef' file type or
> something that simulates a 100% PHP only file, without dropping in and

> out$ of tags and just avoids the use of the <?php ?> nonsense entirely).

You can have that with CLI scripts. But the “<?php … ?>” "nonsense" (and,
more recently, the “<?= … ?>” "nonsense") is actually useful: it allows one
to write programs where the PHP parser only has to do the absolute minimum;
static content can be put verbatim outside of “<?… … ?>”. One must keep in
mind that it is the *P*HP *H*ypertext *P*reprocessor after all; not just any
programming language.

I know of no other language that has this power of avoiding “echo” and
“echo”-like expressions, where the default is *not* to parse content as
source code.

Jerry Stuckle

unread,

Oct 30, 2015, 8:00:54 PM10/30/15

to

On 10/30/2015 5:33 PM, Thomas 'Pointed Head' Lahn wrote:
> Matthew Carter wrote:
>
>> There have been 0 good reasons for including a closing [PHP] tag
>
> ACK.
>

Just what I would expect from you. Good programmers know better.

>> (it's just too bad we can't actually have a '.phpdef' file type or
>> something that simulates a 100% PHP only file, without dropping in and
>> out$ of tags and just avoids the use of the <?php ?> nonsense entirely).
>
> You can have that with CLI scripts. But the “<?php … ?>” "nonsense" (and,
> more recently, the “<?= … ?>” "nonsense") is actually useful: it allows one
> to write programs where the PHP parser only has to do the absolute minimum;
> static content can be put verbatim outside of “<?… … ?>”. One must keep in
> mind that it is the *P*HP *H*ypertext *P*reprocessor after all; not just any
> programming language.
>

Good programming practices is not "nonsense". But you wouldn't know
good programming practices if they bit you in the arse. You've shown
that over and over again.

All you're able to do is copy/paste others' code; you know nothing about
original coding.

> I know of no other language that has this power of avoiding “echo” and
> “echo”-like expressions, where the default is *not* to parse content as
> source code.
>

You don't know much, do you? I suggest you crawl back into your little
hole before you show any more of your ignorance.

Arno Welzel

unread,

Nov 1, 2015, 5:58:29 AM11/1/15

to

Jerry Stuckle schrieb am 2015-10-30 um 21:22:

> On 10/30/2015 3:08 PM, Arno Welzel wrote:
>> Jerry Stuckle schrieb am 2015-10-30 um 03:35:

[...]

>>> But I know you will dismiss any reason given, so go ahead and make a
>>> fool of yourself. You've obviously never worked on a multi-programmer
>>> project with coding conventions.
>>
>> And you seem to never have worked on real production systems. And yes -
>> omitting closing tags *can* be a coding convention within the team as well.
>
> You have no idea. I've worked on MUCH larger production systems than
> you could ever think of. How about one with over 10,000 concurrent
> users, for instance?

You want to play the "my dick is bigger" game? Really? This is your
argument? You loose.

Arno Welzel

unread,

Nov 1, 2015, 6:06:46 AM11/1/15

to

You just don't understand what I'm talking about.

> didn't say PHP existed for decades; I said the good programming
> practices have existed for decades. And PHP is not only NOT the only
> language with closing tags - it is far from the first language with
> closing tags.

That's what I try to say: some practices for OTHER languages which may
exist for decades are NOT relevant for a spepcific feature in PHP! It
seems you have problems understanding me.

BTW: Show languages except PHP which need closing tags at the end of a
file. Oh and to clarify this - I don't talk about brackets for code
blocks. Neither C, C++, C#, Python, Pascal, Fortran, Cobol, Pascal need
closing tags - since the don't need opening tags at the beginning of a
source file either.

> But trolls don't understand that. They're too full of themselves to learn.

As you show here over and over again. Even if the PHP manual recommends
something you argue with.

And your whole whay of insulting other people just because the question
was "is it ok to omit closing tags in PHP?". Don't you have better
things to do than calling all people trolls, idiots and ignorant just
because they don't share your opinion? Your life seems to be very
frustrating for you.

Arno Welzel

unread,

Nov 1, 2015, 6:12:22 AM11/1/15

to

Jerry Stuckle schrieb am 2015-10-30 um 21:27:

> On 10/30/2015 3:01 PM, Arno Welzel wrote:

[...]

>> Well - when changing a script one should do this carefully anyway and
>> not just add HTML without looking at the code. Or do you just blindly
>> add HTML to production code and use it without testing?
>>
>>
>
> Trolls being careful? ROFLMAO! But we know you only exist to raise
> hell on usenet. You don't do any real programming.

So far it seems you are the only troll here. You don't want to discuss
about things, you just want to insult people - and of course you would
never stop as long as you don't have the last word.

Jerry Stuckle

unread,

Nov 1, 2015, 8:27:28 AM11/1/15

to

On 11/1/2015 5:58 AM, Arno Welzel wrote:
> Jerry Stuckle schrieb am 2015-10-30 um 21:22:
>
>> On 10/30/2015 3:08 PM, Arno Welzel wrote:
>>> Jerry Stuckle schrieb am 2015-10-30 um 03:35:
> [...]
>>>> But I know you will dismiss any reason given, so go ahead and make a
>>>> fool of yourself. You've obviously never worked on a multi-programmer
>>>> project with coding conventions.
>>>
>>> And you seem to never have worked on real production systems. And yes -
>>> omitting closing tags *can* be a coding convention within the team as well.
>>
>> You have no idea. I've worked on MUCH larger production systems than
>> you could ever think of. How about one with over 10,000 concurrent
>> users, for instance?
>
> You want to play the "my dick is bigger" game? Really? This is your
> argument? You loose.
>
>

You're the one who brought up the "real production systems", not me. I
don't argue with trolls. I'm just pointing out what a loser you are.

But then all trolls are losers.

Jerry Stuckle

unread,

Nov 1, 2015, 8:29:50 AM11/1/15

to

Oh, I understood, quite well. And it's obvious YOU didn't.

>> didn't say PHP existed for decades; I said the good programming
>> practices have existed for decades. And PHP is not only NOT the only
>> language with closing tags - it is far from the first language with
>> closing tags.
>
> That's what I try to say: some practices for OTHER languages which may
> exist for decades are NOT relevant for a spepcific feature in PHP! It
> seems you have problems understanding me.
>

Good practices are language independent.

> BTW: Show languages except PHP which need closing tags at the end of a
> file. Oh and to clarify this - I don't talk about brackets for code
> blocks. Neither C, C++, C#, Python, Pascal, Fortran, Cobol, Pascal need
> closing tags - since the don't need opening tags at the beginning of a
> source file either.
>

You go find out. I don't waste my time trying to teach trolls. It's
like trying to teach a pig to sing.

>> But trolls don't understand that. They're too full of themselves to learn.
>
> As you show here over and over again. Even if the PHP manual recommends
> something you argue with.
>

Which is, once again, just the opinion of a few programmers - ones I
have little respect for.

> And your whole whay of insulting other people just because the question
> was "is it ok to omit closing tags in PHP?". Don't you have better
> things to do than calling all people trolls, idiots and ignorant just
> because they don't share your opinion? Your life seems to be very
> frustrating for you.
>
>

No, I call trolls what they are. And you have repeatedly shown you are
nothing more than a troll.

Jerry Stuckle

unread,

Nov 1, 2015, 8:31:23 AM11/1/15

to

On 11/1/2015 6:12 AM, Arno Welzel wrote:
> Jerry Stuckle schrieb am 2015-10-30 um 21:27:
>
>> On 10/30/2015 3:01 PM, Arno Welzel wrote:
> [...]
>>> Well - when changing a script one should do this carefully anyway and
>>> not just add HTML without looking at the code. Or do you just blindly
>>> add HTML to production code and use it without testing?
>>>
>>>
>>
>> Trolls being careful? ROFLMAO! But we know you only exist to raise
>> hell on usenet. You don't do any real programming.
>
> So far it seems you are the only troll here. You don't want to discuss
> about things, you just want to insult people - and of course you would
> never stop as long as you don't have the last word.
>
>

Nope, you're the troll - as you've proven time and time again. But then
trolls always try to blame someone else for their shortcomings - as
you've again shown in this thread.

Arno Welzel

unread,

Nov 1, 2015, 8:37:01 AM11/1/15

to

Jerry Stuckle schrieb am 2015-11-01 um 14:27:

> On 11/1/2015 5:58 AM, Arno Welzel wrote:
>> Jerry Stuckle schrieb am 2015-10-30 um 21:22:
>>
>>> On 10/30/2015 3:08 PM, Arno Welzel wrote:
>>>> Jerry Stuckle schrieb am 2015-10-30 um 03:35:
>> [...]
>>>>> But I know you will dismiss any reason given, so go ahead and make a
>>>>> fool of yourself. You've obviously never worked on a multi-programmer
>>>>> project with coding conventions.
>>>>
>>>> And you seem to never have worked on real production systems. And yes -
>>>> omitting closing tags *can* be a coding convention within the team as well.
>>>
>>> You have no idea. I've worked on MUCH larger production systems than
>>> you could ever think of. How about one with over 10,000 concurrent
>>> users, for instance?
>>
>> You want to play the "my dick is bigger" game? Really? This is your
>> argument? You loose.
>>
>>
>
> You're the one who brought up the "real production systems", not me. I
> don't argue with trolls. I'm just pointing out what a loser you are.

And it was you bringing up this:

"But to answer your question - the problem is your test can cause a
fatal error, potentially displaying internal information to a user.
This information could be used to hack the system."

And this is something which will NEVER happen in a production system. A
production system MUST NOT display errors to a user.

You can not be sure that errors will NEVER happen - even when you end
all your scripts with closing tags. Many things can go wrong during
runtime - e.h. database connections may not be available etc.. And for
all these cases you MUST ensure that users will NEVER see error messages
with internal details about the production system. And yes, this is
possible, even for PHP.

So even bringing up the possibility that a *user* of a system may see
error messages with internal information shows me that you either don't
have experience in how to configure and run production systems or you
assume that everybody here is just a hobbyist and does not understand
the difference between a development system and production system.

Arno Welzel

unread,

Nov 1, 2015, 8:39:38 AM11/1/15

to

Jerry Stuckle schrieb am 2015-11-01 um 14:30:

> On 11/1/2015 6:06 AM, Arno Welzel wrote:

[...]

>> As you show here over and over again. Even if the PHP manual recommends
>> something you argue with.
>>
>
> Which is, once again, just the opinion of a few programmers - ones I
> have little respect for.

I can't see anything in
<http://php.net/manual/en/language.basic-syntax.phptags.php> which marks
this as a personal opinion by anyone. It's an official part of the PHP
manual.

Jerry Stuckle

unread,

Nov 1, 2015, 9:05:13 AM11/1/15

to

That's true. And using closing tags is one more step which can prevent it.

> You can not be sure that errors will NEVER happen - even when you end
> all your scripts with closing tags. Many things can go wrong during
> runtime - e.h. database connections may not be available etc.. And for
> all these cases you MUST ensure that users will NEVER see error messages
> with internal details about the production system. And yes, this is
> possible, even for PHP.
>

No, you cannot be sure errors will never happen. You also cannot be
sure that your php.ini file will never be changed. It is NEVER possible
to have 100% assurance that error messages will never be displayed. But
using closing tags is one more level of protection against it happening.

> So even bringing up the possibility that a *user* of a system may see
> error messages with internal information shows me that you either don't
> have experience in how to configure and run production systems or you
> assume that everybody here is just a hobbyist and does not understand
> the difference between a development system and production system.
>
>

The fact you don't consider it possible proves you don't have the
necessary experience to work on a production system. You don't even
rate hobbyist level. You're nothing more than a troll.

Jerry Stuckle

unread,

Nov 1, 2015, 9:06:56 AM11/1/15

to

On 11/1/2015 8:39 AM, Arno Welzel wrote:
> Jerry Stuckle schrieb am 2015-11-01 um 14:30:
>
>> On 11/1/2015 6:06 AM, Arno Welzel wrote:
> [...]
>>> As you show here over and over again. Even if the PHP manual recommends
>>> something you argue with.
>>>
>>
>> Which is, once again, just the opinion of a few programmers - ones I
>> have little respect for.
>
> I can't see anything in
> <http://php.net/manual/en/language.basic-syntax.phptags.php> which marks
> this as a personal opinion by anyone. It's an official part of the PHP
> manual.
>

And where do you think that "official part of the PHP manual" came from?
It is nothing more than the personal opinion of a few programmers -

ones I have little respect for.

But you've never written a manual, so you wouldn't understand what goes
into creating a manual.

Arno Welzel

unread,

Nov 1, 2015, 10:51:21 AM11/1/15

to

Jerry Stuckle schrieb am 2015-11-01 um 15:05:

> On 11/1/2015 8:36 AM, Arno Welzel wrote:
>> Jerry Stuckle schrieb am 2015-11-01 um 14:27:

[...]

>> And it was you bringing up this:
>>
>> "But to answer your question - the problem is your test can cause a
>> fatal error, potentially displaying internal information to a user.
>> This information could be used to hack the system."
>>
>> And this is something which will NEVER happen in a production system. A
>> production system MUST NOT display errors to a user.
>>
>
> That's true. And using closing tags is one more step which can prevent it.

You don't get my point: a production system MUST NOT display errors to a
user - regardless what caused the error.

>> You can not be sure that errors will NEVER happen - even when you end
>> all your scripts with closing tags. Many things can go wrong during
>> runtime - e.h. database connections may not be available etc.. And for
>> all these cases you MUST ensure that users will NEVER see error messages
>> with internal details about the production system. And yes, this is
>> possible, even for PHP.
>>
>
> No, you cannot be sure errors will never happen. You also cannot be
> sure that your php.ini file will never be changed. It is NEVER possible
> to have 100% assurance that error messages will never be displayed. But
> using closing tags is one more level of protection against it happening.

Wrong - mission critical configuration settings MUST stay as defined.
Otherwise the responsible persons should better look for another job.

>> So even bringing up the possibility that a *user* of a system may see
>> error messages with internal information shows me that you either don't
>> have experience in how to configure and run production systems or you
>> assume that everybody here is just a hobbyist and does not understand
>> the difference between a development system and production system.
>>
>>
>
> The fact you don't consider it possible proves you don't have the
> necessary experience to work on a production system. You don't even
> rate hobbyist level. You're nothing more than a troll.

I don't know what you consider "professional" - but I wouldn't consider
stupid things like allowing internal error messages to be disaplayed to
the user on a production system just because one of the developers
created a formal error in one of his scripts and putting them to the
production system without testing it. I would also never let a software
developer touch the php.ini of a production system without doing a
review or even let anyone put scripts to production without testing at all.

Arno Welzel

unread,

Nov 1, 2015, 10:58:49 AM11/1/15

to

Jerry Stuckle schrieb am 2015-11-01 um 15:07:

> On 11/1/2015 8:39 AM, Arno Welzel wrote:
>> Jerry Stuckle schrieb am 2015-11-01 um 14:30:
>>
>>> On 11/1/2015 6:06 AM, Arno Welzel wrote:
>> [...]
>>>> As you show here over and over again. Even if the PHP manual recommends
>>>> something you argue with.
>>>>
>>>
>>> Which is, once again, just the opinion of a few programmers - ones I
>>> have little respect for.
>>
>> I can't see anything in
>> <http://php.net/manual/en/language.basic-syntax.phptags.php> which marks
>> this as a personal opinion by anyone. It's an official part of the PHP
>> manual.
>>
>
> And where do you think that "official part of the PHP manual" came from?

Irrelevant. It is part of the official technical documentation of PHP.

> It is nothing more than the personal opinion of a few programmers -
> ones I have little respect for.

So you have little respect for the developers of PHP itself? Why do you
use the language it then? Did you also tell exactly this to the
maintainers of the PHP manual?

> But you've never written a manual, so you wouldn't understand what goes
> into creating a manual.

Don't worry - I have written manuals and know very well what I'm talking
about.

Jerry Stuckle

unread,

Nov 1, 2015, 11:05:42 AM11/1/15

to

On 11/1/2015 10:58 AM, Arno Welzel wrote:
> Jerry Stuckle schrieb am 2015-11-01 um 15:07:
>
>> On 11/1/2015 8:39 AM, Arno Welzel wrote:
>>> Jerry Stuckle schrieb am 2015-11-01 um 14:30:
>>>
>>>> On 11/1/2015 6:06 AM, Arno Welzel wrote:
>>> [...]
>>>>> As you show here over and over again. Even if the PHP manual recommends
>>>>> something you argue with.
>>>>>
>>>>
>>>> Which is, once again, just the opinion of a few programmers - ones I
>>>> have little respect for.
>>>
>>> I can't see anything in
>>> <http://php.net/manual/en/language.basic-syntax.phptags.php> which marks
>>> this as a personal opinion by anyone. It's an official part of the PHP
>>> manual.
>>>
>>
>> And where do you think that "official part of the PHP manual" came from?
>
> Irrelevant. It is part of the official technical documentation of PHP.
>

So? That does not mean it is good programming practices.

>> It is nothing more than the personal opinion of a few programmers -
>> ones I have little respect for.
>
> So you have little respect for the developers of PHP itself? Why do you
> use the language it then? Did you also tell exactly this to the
> maintainers of the PHP manual?
>

Both. And why I use it is none of your business.

>> But you've never written a manual, so you wouldn't understand what goes
>> into creating a manual.
>
> Don't worry - I have written manuals and know very well what I'm talking
> about.
>
>

Ah, yes - "The Dummies Guide to Trolling". If forgot about that one!

Jerry Stuckle

unread,

Nov 1, 2015, 11:08:49 AM11/1/15

to

On 11/1/2015 10:51 AM, Arno Welzel wrote:
> Jerry Stuckle schrieb am 2015-11-01 um 15:05:
>
>> On 11/1/2015 8:36 AM, Arno Welzel wrote:
>>> Jerry Stuckle schrieb am 2015-11-01 um 14:27:
> [...]
>>> And it was you bringing up this:
>>>
>>> "But to answer your question - the problem is your test can cause a
>>> fatal error, potentially displaying internal information to a user.
>>> This information could be used to hack the system."
>>>
>>> And this is something which will NEVER happen in a production system. A
>>> production system MUST NOT display errors to a user.
>>>
>>
>> That's true. And using closing tags is one more step which can prevent it.
>
> You don't get my point: a production system MUST NOT display errors to a
> user - regardless what caused the error.
>

Oh, I get your point. And you're wrong in thinking it can never happen.

>
>>> You can not be sure that errors will NEVER happen - even when you end
>>> all your scripts with closing tags. Many things can go wrong during
>>> runtime - e.h. database connections may not be available etc.. And for
>>> all these cases you MUST ensure that users will NEVER see error messages
>>> with internal details about the production system. And yes, this is
>>> possible, even for PHP.
>>>
>>
>> No, you cannot be sure errors will never happen. You also cannot be
>> sure that your php.ini file will never be changed. It is NEVER possible
>> to have 100% assurance that error messages will never be displayed. But
>> using closing tags is one more level of protection against it happening.
>
> Wrong - mission critical configuration settings MUST stay as defined.
> Otherwise the responsible persons should better look for another job.
>

Wrong again. You can NEVER guarantee something won't happen. All you
can to is to protect as well as you can.

>
>>> So even bringing up the possibility that a *user* of a system may see
>>> error messages with internal information shows me that you either don't
>>> have experience in how to configure and run production systems or you
>>> assume that everybody here is just a hobbyist and does not understand
>>> the difference between a development system and production system.
>>>
>>>
>>
>> The fact you don't consider it possible proves you don't have the
>> necessary experience to work on a production system. You don't even
>> rate hobbyist level. You're nothing more than a troll.
>
> I don't know what you consider "professional" - but I wouldn't consider
> stupid things like allowing internal error messages to be disaplayed to
> the user on a production system just because one of the developers
> created a formal error in one of his scripts and putting them to the
> production system without testing it. I would also never let a software
> developer touch the php.ini of a production system without doing a
> review or even let anyone put scripts to production without testing at all.
>
>

Something other than what you are, that's for sure. You don't
understand even basic good programming practices used by professionals.

Arno Welzel

unread,

Nov 2, 2015, 2:14:31 AM11/2/15

to

Jerry Stuckle schrieb am 2015-11-01 um 17:05:

> On 11/1/2015 10:58 AM, Arno Welzel wrote:

[...]

>> So you have little respect for the developers of PHP itself? Why do you
>> use the language it then? Did you also tell exactly this to the
>> maintainers of the PHP manual?
>>
>
> Both. And why I use it is none of your business.

I see - you have little respect for the developers of PHP itself and you
see recommendations in their manual as a bad programming practice.

And you really think your advises about *any* PHP related topic here
should be taken seriously? Really?

Erwin Moller

unread,

Nov 2, 2015, 7:51:53 AM11/2/15

to

On 10/30/2015 2:44 AM, Matthew Carter wrote:
> Erwin Moller <erwinmol...@xs4all.nl> writes:
>
>> On 10/28/2015 4:29 AM, Jerry Stuckle wrote:
>>>
>>> YOU don't see any problem. Good programmers do.
>>>
>>> Just wait until you run into a problem because of it. Your tune will
>>> change. And I'm not the only one who feels this way.
>>>
>>
>> Seconded.
>> Always use the closing tag.
>>
>> <opinionated>
>> If you get into trouble because you produce output after the closing
>> tag, get another job.
>> If that is over your head, you should change jobs, not the programming
>> language (or usage of it).
>> It isn't that hard.
>> This advice from php.net is ridiculous.
>>
>> This reminds me a lot of the curly bracket in conditional statements.
>> Some seem to think omitting them is alright for single statements.
>> It is, of course, not alright to omit them.
>> </opinionated>
>>
>> Regards,
>> Erwin Moller
>
> Other than a feeling of self righteousness, what is gained again?

A fair question.

To name a few:
- Estatics.
- No violation of the reasonable expectation that an opening tag should
be accompanied by a closing tag.
- Slightly better readable code.
- Resistance to pop-culture programming (!).

But being self-righteous is enough reason in itself, for me.
(However, that was not the reason I jumped into this thread.)

>
> Tell me, in these two sample files, which is easier to debug if the
> aforementioned use cases occurred that cause an error when the file is
> included by another file making use of header responses:
>
> ------------------File One (no closing tag, misplaced HTML)-----------
> <?php
>
> function add($a, $b) {
> return $a + $b;
> }
>
> <h1>This is my great page of addition!</h1>
>
> ------------------File Two (closing tag, extra space)-----------------
> <?php
>
> function add($a, $b) {
> return $a + $b;
> }
>
> ?>

People who include files and put whitespaces after the closing tag will
quickly see the infamous "Output created before headers bla bla, etc
etc." error.

Hmmm, HUGE PROBLEM! Now what?

We have a few choices:
1) Remove the offending whitespace, and tell the programmer NOT to do
that again.
2) Change the language, violate the logical assumption that each opening
tag should be accompanied by a closing tag.

It is beyond my understanding how anyone can opt for the second option.
What is even more flabberghasting is the fact many people are willing to
defend that crazy decision.

>
>
> Assuming both were included/required in another file, which one would
> the majority of programmers have an easier time pinpointing the error
> with? (hint: the one where the PHP error reporting would tell you
> exactly where the faulty HTML was originating, NOT the file that was
> outputting some whitespace before a header call - that error would send
> you to the header() call line, not the bad file with trailing space).

Yes, you set up this question in such a way I can only agree with your
precooked assumption. Of course the whitespace in your second example is
harder to find.
So yes, you are right in this situation.

I DO want to add that if I save a file I have been working on, I test
the results. If I see that "output created before header blabla etc
etc", I think I know where to look first.
And that is my point: It isn't hard to find this problem.
And the "solution" you are defending is plain ugly, counter-intuitive,
and introduces its own set of new possible problems.

On a sidenote: Your example is barely realistic. In each simple IDE
(well, even Notepad++) your first example will shine out with colors,
because there is HTML found where PHP is expected.

I hope you understand what I am saying.

And if some programmer REALLY has trouble avoiding whitespaces after the
closing tag, write some simple bash script, that checks for them.
(I never needed that, but it is easy to write: just match the last ?>
and see if anything follows)

>
> There have been 0 good reasons for including a closing tag (it's just too
> bad we can't actually have a '.phpdef' file type or something that
> simulates a 100% PHP only file, without dropping in and out of tags and
> just avoids the use of the <?php ?> nonsense entirely).
>

I fail, and keep failing, to see the importance of this.
We programmers have puzzles and problems to be solved daily.
Finding an unintended whitespace isn't really a big part of my daily
business......

This solves a problem that didn't have to be solved, and it made the
language uglier.

Regards,
Erwin Moller

--
"That which can be asserted without evidence, can be dismissed without
evidence."
-- Christopher Hitchens

Jerry Stuckle

unread,

Nov 2, 2015, 10:01:44 AM11/2/15

to

On 11/2/2015 2:14 AM, Arno Welzel wrote:
> Jerry Stuckle schrieb am 2015-11-01 um 17:05:
>
>> On 11/1/2015 10:58 AM, Arno Welzel wrote:
> [...]
>>> So you have little respect for the developers of PHP itself? Why do you
>>> use the language it then? Did you also tell exactly this to the
>>> maintainers of the PHP manual?
>>>
>>
>> Both. And why I use it is none of your business.
>
> I see - you have little respect for the developers of PHP itself and you
> see recommendations in their manual as a bad programming practice.
>

No, I have little respect for the developers of PHP BECAUSE they make
recommendations that violate long-standing good programming practices.

> And you really think your advises about *any* PHP related topic here
> should be taken seriously? Really?
>
>

Much more than anything a troll like YOU suggests should be taken seriously.

And it's "advice", not "advises". Point in fact.

Arno Welzel

unread,

Nov 2, 2015, 11:54:19 AM11/2/15

to

Jerry Stuckle schrieb am 2015-11-02 um 16:01:

[...]

> Much more than anything a troll like YOU suggests should be taken seriously.
>
> And it's "advice", not "advises". Point in fact.

Wenn Du jemals Deutsch schreibst, werde ich Dich dann auch auf jeden
Rechtschreibfehler hinweisen - Danke.

Jerry Stuckle

unread,

Nov 2, 2015, 12:50:47 PM11/2/15

to

On 11/2/2015 11:54 AM, Arno Welzel wrote:
> Jerry Stuckle schrieb am 2015-11-02 um 16:01:
>
> [...]
>> Much more than anything a troll like YOU suggests should be taken seriously.
>>
>> And it's "advice", not "advises". Point in fact.
>
> Wenn Du jemals Deutsch schreibst, werde ich Dich dann auch auf jeden
> Rechtschreibfehler hinweisen - Danke.
>
>

Poor Arno.

I never claimed to understand German very well. You, though, have
claimed to be proficient in English. Just showing you that you aren't
nearly as proficient as you think you are.

Arno Welzel

unread,

Nov 2, 2015, 12:57:33 PM11/2/15

to

Erwin Moller schrieb am 2015-11-02 um 13:51:

> On 10/30/2015 2:44 AM, Matthew Carter wrote:

[...]

>> Tell me, in these two sample files, which is easier to debug if the
>> aforementioned use cases occurred that cause an error when the file is
>> included by another file making use of header responses:
>>
>> ------------------File One (no closing tag, misplaced HTML)-----------
>> <?php
>>
>> function add($a, $b) {
>> return $a + $b;
>> }
>>
>> <h1>This is my great page of addition!</h1>
>>
>> ------------------File Two (closing tag, extra space)-----------------
>> <?php
>>
>> function add($a, $b) {
>> return $a + $b;
>> }
>>
>> ?>
>
>
> People who include files and put whitespaces after the closing tag will
> quickly see the infamous "Output created before headers bla bla, etc
> etc." error.

This will just happen, if a scripts wants to add headers which is not
always the case.

> Hmmm, HUGE PROBLEM! Now what?
>
> We have a few choices:
> 1) Remove the offending whitespace, and tell the programmer NOT to do
> that again.

And hope that he will obey this rule. More likely this will happen again
many times.

> 2) Change the language, violate the logical assumption that each opening
> tag should be accompanied by a closing tag.
>
>
> It is beyond my understanding how anyone can opt for the second option.

You will do this, when you first had to spend hours in finding bugs in a
system which consist of hundreds of files and some problem shows up
caused by unintentional whitespaces.

> What is even more flabberghasting is the fact many people are willing to
> defend that crazy decision.

As already mentioned by T. Lahn:

<http://www.php-fig.org/psr/psr-2/>

Cite:

"The closing ?> tag MUST be omitted from files containing only PHP."

[...]

> And if some programmer REALLY has trouble avoiding whitespaces after the
> closing tag, write some simple bash script, that checks for them.
> (I never needed that, but it is easy to write: just match the last ?>
> and see if anything follows)

Before I create a script to check other scripts I would just omit the
closing tag - then I don't need any "check scripts" at all ;-).

>> There have been 0 good reasons for including a closing tag (it's just too
>> bad we can't actually have a '.phpdef' file type or something that
>> simulates a 100% PHP only file, without dropping in and out of tags and
>> just avoids the use of the <?php ?> nonsense entirely).
>>
>
> I fail, and keep failing, to see the importance of this.
> We programmers have puzzles and problems to be solved daily.
> Finding an unintended whitespace isn't really a big part of my daily
> business......
>
> This solves a problem that didn't have to be solved, and it made the
> language uglier.

PHP is already ugly in many places.

Arno Welzel

unread,

Nov 2, 2015, 1:05:09 PM11/2/15

to

Jerry Stuckle schrieb am 2015-11-02 um 18:50:

> On 11/2/2015 11:54 AM, Arno Welzel wrote:
>> Jerry Stuckle schrieb am 2015-11-02 um 16:01:
>>
>> [...]
>>> Much more than anything a troll like YOU suggests should be taken seriously.
>>>
>>> And it's "advice", not "advises". Point in fact.
>>
>> Wenn Du jemals Deutsch schreibst, werde ich Dich dann auch auf jeden
>> Rechtschreibfehler hinweisen - Danke.
>>
>>
>
> Poor Arno.
>
> I never claimed to understand German very well. You, though, have
> claimed to be proficient in English. Just showing you that you aren't
> nearly as proficient as you think you are.

I can't remember that I ever claimed to be proficient in English neither
I understand what a single typo has to with proficiency in a language.

At least you understand what I write and you call me a troll. So my
English it can not be too bad ;-).

Jerry Stuckle

unread,

Nov 2, 2015, 3:16:17 PM11/2/15

to

Oh, you have claimed many times you understand what was said in this
newsgroups - even though you obviously did not.

And yes, you are a troll - as evinced by your repeated posting of
unmunged email addresses in attempts to get newsgroup users spammed.

Jerry Stuckle

unread,

Nov 2, 2015, 3:23:32 PM11/2/15

to

On 11/2/2015 1:23 PM, Tim Streater wrote:
> In article <5637A5CC...@arnowelzel.de>, Arno Welzel

> <use...@arnowelzel.de> wrote:
>
>> At least you understand what I write and you call me a troll. So my
>> English it can not be too bad ;-).
>

> It's not too bad at all, Arno - really. That is a frequent error,
> however:
>
> advice - noun
> advise - verb
>

Any middle school student should understand the difference.
Unfortunately, there are a number of undereducated people in this country.

> I blame Jerry and his fellow Americans, myself. Their attempts to make
> English spelling more, err, more what? I'm not sure I know. Anyway they
> say:
>
> license - verb and noun
>
> whereas we say:
>
> licence - noun
> license - verb
>
> (Cue spelling argument until the end of time)
>

Actually, not. License can be a noun or a verb, as can licence. The
former is generally considered the correct spelling in the U.S., while
the latter in the U.K.

Arno Welzel

unread,

Nov 2, 2015, 11:47:47 PM11/2/15

to

Jerry Stuckle schrieb am 2015-11-02 um 21:16:

> On 11/2/2015 1:05 PM, Arno Welzel wrote:
>> Jerry Stuckle schrieb am 2015-11-02 um 18:50:

[...]

>>> I never claimed to understand German very well. You, though, have
>>> claimed to be proficient in English. Just showing you that you aren't
>>> nearly as proficient as you think you are.
>>
>> I can't remember that I ever claimed to be proficient in English neither
>> I understand what a single typo has to with proficiency in a language.
>>
>> At least you understand what I write and you call me a troll. So my
>> English it can not be too bad ;-).
>>
>>
>>
>
> Oh, you have claimed many times you understand what was said in this
> newsgroups - even though you obviously did not.

And this you call "claiming to be proficient in English"?

> And yes, you are a troll - as evinced by your repeated posting of
> unmunged email addresses in attempts to get newsgroup users spammed.

You take yourself way too seriously. You really believe spammers will
scan the body of usenet postings to find working e-mail-addresses?

And if so - don't you think, spammers are not smart enough to get your
address from mailing list archives, like this one:

<https://lists.debian.org/debian-user/2014/10/msg00415.html>

Further reading - even if you ignore this anway, but maybe helpful for
others:

<https://tools.ietf.org/html/rfc1849#section-5.2>
<http://www.interhack.net/pubs/munging-harmful/>
<http://web.mit.edu/dmaze/www/nospam.html>

BTW: use...@arnowelzel.de is valid and will be read.

Jerry Stuckle

unread,

Nov 3, 2015, 8:47:27 AM11/3/15

to

On 11/2/2015 11:47 PM, Arno Welzel wrote:
> Jerry Stuckle schrieb am 2015-11-02 um 21:16:
>
>> On 11/2/2015 1:05 PM, Arno Welzel wrote:
>>> Jerry Stuckle schrieb am 2015-11-02 um 18:50:
> [...]
>>>> I never claimed to understand German very well. You, though, have
>>>> claimed to be proficient in English. Just showing you that you aren't
>>>> nearly as proficient as you think you are.
>>>
>>> I can't remember that I ever claimed to be proficient in English neither
>>> I understand what a single typo has to with proficiency in a language.
>>>
>>> At least you understand what I write and you call me a troll. So my
>>> English it can not be too bad ;-).
>>>
>>>
>>>
>>
>> Oh, you have claimed many times you understand what was said in this
>> newsgroups - even though you obviously did not.
>
> And this you call "claiming to be proficient in English"?
>

No, it's YOUR claim.

>> And yes, you are a troll - as evinced by your repeated posting of
>> unmunged email addresses in attempts to get newsgroup users spammed.
>
> You take yourself way too seriously. You really believe spammers will
> scan the body of usenet postings to find working e-mail-addresses?
>

Yes, they do - and regularly. But then that's why you did it.

> And if so - don't you think, spammers are not smart enough to get your
> address from mailing list archives, like this one:
>
> <https://lists.debian.org/debian-user/2014/10/msg00415.html>
>

Nothing I can do about that.

> Further reading - even if you ignore this anway, but maybe helpful for
> others:
>
> <https://tools.ietf.org/html/rfc1849#section-5.2>
> <http://www.interhack.net/pubs/munging-harmful/>
> <http://web.mit.edu/dmaze/www/nospam.html>
>

The RFC specifies what the header contains and the valid characters. No
where does it state it MUST contain a valid email address.

The interhack.net post is one person's opinion, and over 17 years old.

And the mit.edu post is just another opinion - but the same person.

You can also find claims the world is flat on the internet.

> BTW: use...@arnowelzel.de is valid and will be read.
>
>

So? The bottom line here is - you are a troll, as you have yourself
proven. You can't get out of it - everyone who reads this newsgroup can
see that.

Thomas 'PointedEars' Lahn

unread,

Nov 3, 2015, 1:51:23 PM11/3/15

to

Thomas 'PointedEars' Lahn wrote:

> Matthew Carter wrote:
>> (it's just too bad we can't actually have a '.phpdef' file type or
>> something that simulates a 100% PHP only file, without dropping in and

>> out$ of tags and just avoids the use of the <?php ?> nonsense entirely).
>
> You can have that with CLI scripts. […]

I stand corrected by myself. Unless I have overlooked something, apparently
it is necessary to use “<?php” in CLI scripts, too. I do not usually write
CLI scripts (hence my misconception), but a few days ago I decided to do
that. When I ran the script file (its executable attribute was set) on
GNU/Linux in Bash, the code was not parsed as PHP (but output verbatim
instead), and not syntax-highlighted in Vim, until I had used “<?php”.

The current version of the script is rather short, so it might serve as a
PHP (5.4+) learning exercise (it certainly did for me – who would have
thought that you can use libxml to parse borked HTML, and not only apply
XPath to the result, but get the .innerHTML of elements this easily [I have
used several approaches from examples in the PHP manual and answers on Stack
Overflow – along with the user comments in the manual a virtual treasure
trove of ideas]):

#!/usr/bin/env php5
<?php

$page = 1;
$dict_template = 'http://wayback.archive.org/web/20150317193733/' .
'http://home.comcast.net/~markg61/gv-eng%s.htm';
$libxml_options = (LIBXML_COMPACT | LIBXML_NOBLANKS | LIBXML_NOENT
| LIBXML_NOWARNING);
$ipa_map = [
'aa' => 'ɑ',
'g' => json_decode('"\\u0261"'),
'l' => 'l',
];

$d = new DOMDocument();
while ($d->loadHTMLFile(sprintf($dict_template, $page), $libxml_options))
{
$r = (new DOMXPath($d))->query("//ul");
echo preg_replace_callback(
'/<img src="([^.]+).gif">/',
function ($match) use ($ipa_map) {
$char = $match[1];
return @$ipa_map[$char] ? $ipa_map[$char] : $match[0];
},
preg_replace('/<\\/?font[^>]*>|<br>(?:\r|$)?/', '',
$d->saveHTML($r[7]->firstChild))
);

++$page;
}

(Suggestions for improvement are welcome. I can foresee one suggestion
already: Use output buffering :))

--
PointedEars
Zend Certified PHP Engineer
Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

Arno Welzel

unread,

Nov 3, 2015, 9:55:42 PM11/3/15

to

Jerry Stuckle schrieb am 2015-11-03 um 14:47:

[...]

> So? The bottom line here is - you are a troll, as you have yourself
> proven. You can't get out of it - everyone who reads this newsgroup can
> see that.

The bottom line is that you are an old sociopath who should get a life.

Jerry Stuckle

unread,

Nov 3, 2015, 10:10:04 PM11/3/15

to

On 11/3/2015 9:55 PM, Arno Welzel wrote:
> Jerry Stuckle schrieb am 2015-11-03 um 14:47:
>
> [...]
>> So? The bottom line here is - you are a troll, as you have yourself
>> proven. You can't get out of it - everyone who reads this newsgroup can
>> see that.
>
> The bottom line is that you are an old sociopath who should get a life.
>
>

ROFLMAO! This from a troll who purposely tries to get other users
spammed. Talk about SICK!

But then trolls always blame other people for their own failings. And
you've proven repeatedly you are nothing more than a troll.

Arno Welzel

unread,

Nov 4, 2015, 2:49:38 AM11/4/15

to

Jerry Stuckle schrieb am 2015-11-04 um 04:09:

> On 11/3/2015 9:55 PM, Arno Welzel wrote:
>> Jerry Stuckle schrieb am 2015-11-03 um 14:47:
>>
>> [...]
>>> So? The bottom line here is - you are a troll, as you have yourself
>>> proven. You can't get out of it - everyone who reads this newsgroup can
>>> see that.
>>
>> The bottom line is that you are an old sociopath who should get a life.
>>
>>
>
> ROFLMAO! This from a troll who purposely tries to get other users
> spammed. Talk about SICK!
>
> But then trolls always blame other people for their own failings. And
> you've proven repeatedly you are nothing more than a troll.

How often do you want to repeat this? Do you climax when saying the word
"troll"?

Jerry Stuckle

unread,

Nov 4, 2015, 8:29:59 AM11/4/15

to

On 11/4/2015 2:49 AM, Arno Welzel wrote:
> Jerry Stuckle schrieb am 2015-11-04 um 04:09:
>
>> On 11/3/2015 9:55 PM, Arno Welzel wrote:
>>> Jerry Stuckle schrieb am 2015-11-03 um 14:47:
>>>
>>> [...]
>>>> So? The bottom line here is - you are a troll, as you have yourself
>>>> proven. You can't get out of it - everyone who reads this newsgroup can
>>>> see that.
>>>
>>> The bottom line is that you are an old sociopath who should get a life.
>>>
>>>
>>
>> ROFLMAO! This from a troll who purposely tries to get other users
>> spammed. Talk about SICK!
>>
>> But then trolls always blame other people for their own failings. And
>> you've proven repeatedly you are nothing more than a troll.
>
> How often do you want to repeat this? Do you climax when saying the word
> "troll"?
>
>

You just hate it when someone tells you what you are, don't you? Trolls
are like that.

Paul Herber

unread,

Nov 4, 2015, 9:14:16 AM11/4/15

to

Why don't you both give it a rest? Neither of you gain status from this stupid argument,
in fact, quite the opposite.

I bet one of you responds to this to continue the argument.

--
Regards, Paul Herber
http://www.paulherber.co.uk/

Erwin Moller

unread,

Nov 4, 2015, 9:18:39 AM11/4/15

to

On 11/2/2015 6:57 PM, Arno Welzel wrote:
> Erwin Moller schrieb am 2015-11-02 um 13:51:

<snip>

>> People who include files and put whitespaces after the closing tag
>> will quickly see the infamous "Output created before headers bla
>> bla, etc etc." error.
>
> This will just happen, if a scripts wants to add headers which is not
> always the case.
>
>
>> Hmmm, HUGE PROBLEM! Now what?
>>
>> We have a few choices:
>> 1) Remove the offending whitespace, and tell the programmer NOT to do
>> that again.
>
> And hope that he will obey this rule. More likely this will happen
> again many times.

Is it really that hard?
And why accept it when "programmers" make this mistake, and refuse to
improve their act?

>
>> 2) Change the language, violate the logical assumption that each
>> opening tag should be accompanied by a closing tag.
>>
>>
>> It is beyond my understanding how anyone can opt for the second
>> option.
>
> You will do this, when you first had to spend hours in finding bugs
> in a system which consist of hundreds of files and some problem shows
> up caused by unintentional whitespaces.

No, that would not change my mind.
I know how hard it can be to find bugs, especially on a huge codebase.
I feel your pain.
But cure is worse than the pain.

The reason I make such a fuzz about this is this:
Where does this kind of "improvements" end?

Do you think it is acceptable if all calls to a method or function that
cannot be found will be replaced (by the language) by the one that
closely resembles the spelling used in the code because sometimes people
mistype the name of the function, or are confused by camelCase/CamelCase?

Do you think it is acceptable if programmers leave out the closing curly
bracket in conditional statement, because they "forget sometimes" to
close it, and you have spend hours finding the problem?

Really, sometimes you just have to draw a line, and demand a certain
mastery of the job. If people cannot deliver, they should go elsewhere.

>
>> What is even more flabberghasting is the fact many people are willing to
>> defend that crazy decision.
>
> As already mentioned by T. Lahn:
>
> <http://www.php-fig.org/psr/psr-2/>
>
> Cite:
>
> "The closing ?> tag MUST be omitted from files containing only PHP."
>

I choose to respond with:

https://yourlogicalfallacyis.com/appeal-to-authority

And Thomas Pointedears Lahn replaced critical thinking with following
guidelines to the letter, a long time ago.
My advice: Don't follow him there.

Jerry Stuckle

unread,

Nov 4, 2015, 10:00:56 AM11/4/15

to

On 11/4/2015 9:14 AM, Paul Herber wrote:
> Why don't you both give it a rest? Neither of you gain status from this stupid argument,
> in fact, quite the opposite.
>
> I bet one of you responds to this to continue the argument.
>

You really don't think you can jump into a conversation and not get a
reply, do you?

I just think it's funny to see how many accusations the troll can come
up with about me, trying to get a major reaction. He can't make a
bigger fool of himself than he is, but he just doesn't see it.

Matthew Carter

unread,

Nov 4, 2015, 9:18:55 PM11/4/15

to

Symfony 2 framework already provides suggestions if you mispell a word
in the error output above the stack trace (did you mean XYZ instead of
XWZ? type of thing).

Although in PHP camelCase will never get you in functions/methods, as
they're all case insensitive :)

<?php

function blub() {
echo 1;
}

BLUB();

class foo
{
public function bar()
{
echo 2;
}
}

$f = new foo();
$f->BAR();

--
Matthew Carter (m...@ahungry.com)
http://ahungry.com

Arno Welzel

unread,

Nov 5, 2015, 1:51:57 AM11/5/15

to

Erwin Moller schrieb am 2015-11-04 um 15:18:

> On 11/2/2015 6:57 PM, Arno Welzel wrote:
> > Erwin Moller schrieb am 2015-11-02 um 13:51:

[...]

> >> 2) Change the language, violate the logical assumption that each
> >> opening tag should be accompanied by a closing tag.
> >>
> >>
> >> It is beyond my understanding how anyone can opt for the second
> >> option.
> >
> > You will do this, when you first had to spend hours in finding bugs
> > in a system which consist of hundreds of files and some problem shows
> > up caused by unintentional whitespaces.
>
> No, that would not change my mind.
> I know how hard it can be to find bugs, especially on a huge codebase.
> I feel your pain.
> But cure is worse than the pain.

No - the cure is an official recommendation, as already mentioned
several times:

<http://php.net/manual/en/language.basic-syntax.phptags.php>

> The reason I make such a fuzz about this is this:
> Where does this kind of "improvements" end?

It is not an "improvement" - it's just part of the language PHP and
totally valid.

> Do you think it is acceptable if all calls to a method or function that
> cannot be found will be replaced (by the language) by the one that
> closely resembles the spelling used in the code because sometimes people
> mistype the name of the function, or are confused by camelCase/CamelCase?

No. And you start to mix up things which have nothing to do with each other.

> Do you think it is acceptable if programmers leave out the closing curly
> bracket in conditional statement, because they "forget sometimes" to
> close it, and you have spend hours finding the problem?

No. And this also has nothing to do with the topic.

And as you introduced it - that's my response for this ;-)

<https://yourlogicalfallacyis.com/slippery-slope>

> Really, sometimes you just have to draw a line, and demand a certain
> mastery of the job. If people cannot deliver, they should go elsewhere.

I don't think this applies here.

> >> What is even more flabberghasting is the fact many people are willing to
> >> defend that crazy decision.
> >
> > As already mentioned by T. Lahn:
> >
> > <http://www.php-fig.org/psr/psr-2/>
> >
> > Cite:
> >
> > "The closing ?> tag MUST be omitted from files containing only PHP."
> >
>
> I choose to respond with:
>
> https://yourlogicalfallacyis.com/appeal-to-authority

Wrong.

I explained why I believe that it makes sense to omit closing tags in
PHP scripts to avoid an unintentional whitespace without - and my
argument was NOT that one should do just it, because some authority says
to do so! But since some people say that omitting a closing tag at the
end of a PHP script is just a dirty workaround I referred to
<http://php.net/manual/en/language.basic-syntax.phptags.php> and
<http://www.php-fig.org/psr/psr-2/> to show that *others* recommend this
as well - including the staff of PHP itself.

Thomas 'PointedEars' Lahn

unread,

Nov 6, 2015, 7:11:50 AM11/6/15

to

Arno Welzel wrote:

> Jerry Stuckle schrieb am 2015-11-04 um 04:09:
>> But then trolls always blame other people for their own failings. And
>> you've proven repeatedly you are nothing more than a troll.
>
> How often do you want to repeat this? Do you climax when saying the word
> "troll"?

Words of wisdom:

“Never argue with an idiot, onlookers won’t be able to tell the
difference.” – Mark Twain, writer (1835–1910)

“Never argue with an idiot. They will only bring you down to their level and
beat you with experience.” – George Carlin, actor (1937–2008)

Actually, it is a very old wisdom that I, too, should consider more often,
thereby using my precious free time more efficiently:

<http://biblehub.com/proverbs/23-9.htm>

Jerry Stuckle

unread,

Nov 6, 2015, 9:45:09 AM11/6/15

to

On 11/6/2015 7:11 AM, Thomas 'PointedEars' Lahn wrote:
> Arno Welzel wrote:
>
>> Jerry Stuckle schrieb am 2015-11-04 um 04:09:
>>> But then trolls always blame other people for their own failings. And
>>> you've proven repeatedly you are nothing more than a troll.
>>
>> How often do you want to repeat this? Do you climax when saying the word
>> "troll"?
>
> Words of wisdom:
>
> “Never argue with an idiot, onlookers won’t be able to tell the
> difference.” – Mark Twain, writer (1835–1910)
>
> “Never argue with an idiot. They will only bring you down to their level and
> beat you with experience.” – George Carlin, actor (1937–2008)
>
> Actually, it is a very old wisdom that I, too, should consider more often,
> thereby using my precious free time more efficiently:
>
> <http://biblehub.com/proverbs/23-9.htm>
>

LOL, "words of wisdom" from a well known troll (in multiple newsgroups)!

Just one troll talking to another.

Matthew Carter

unread,

Nov 7, 2015, 9:50:14 PM11/7/15

to

Jerry Stuckle <jstu...@attglobal.net> writes:

> On 11/6/2015 7:11 AM, Thomas 'PointedEars' Lahn wrote:
>> Arno Welzel wrote:
>>
>>> Jerry Stuckle schrieb am 2015-11-04 um 04:09:
>>>> But then trolls always blame other people for their own failings. And
>>>> you've proven repeatedly you are nothing more than a troll.
>>>
>>> How often do you want to repeat this? Do you climax when saying the word
>>> "troll"?
>>
>> Words of wisdom:
>>
>> “Never argue with an idiot, onlookers won’t be able to tell the
>> difference.” – Mark Twain, writer (1835–1910)
>>
>> “Never argue with an idiot. They will only bring you down to their level and
>> beat you with experience.” – George Carlin, actor (1937–2008)
>>
>> Actually, it is a very old wisdom that I, too, should consider more often,
>> thereby using my precious free time more efficiently:
>>
>> <http://biblehub.com/proverbs/23-9.htm>
>>
>
> LOL, "words of wisdom" from a well known troll (in multiple newsgroups)!
>
> Just one troll talking to another.

Too lazy to make a meme, this one seems fitting though:

http://cdn.meme.am/instances/400x/57142799.jpg

Jerry Stuckle

unread,

Nov 7, 2015, 10:05:46 PM11/7/15

to

So we have another troll here, huh?

Gordon Burditt

unread,

Nov 8, 2015, 9:50:22 PM11/8/15

to

> You take yourself way too seriously. You really believe spammers will
> scan the body of usenet postings to find working e-mail-addresses?

I do, and I think I've proved it. I put an email address like this:

spamsucks.f1d2d2f924e986a...@burditt.org

into the body of a USENET post, and scan the server logs for that
address after a few days. I don't ALWAYS get email at an address
lik that, but it happens sometimes. I've seen spams with such an
address show up even after a few years from the one time I put that
address in a post. The chance of a spammer guessing that long mess
of hex digits is a lot less than spammers extracting email addresses
from USENET posts (and, for that matter, from HTML on web sites).

Arno Welzel

unread,

Nov 9, 2015, 4:29:43 AM11/9/15

to

I stand corrected. But I believe this is fetched from websites who
provide usenet archives (Google groups etc.) and of not via NNTP.

Gordon Burditt

unread,

Nov 11, 2015, 12:43:03 AM11/11/15

to

>>> You take yourself way too seriously. You really believe spammers will
>>> scan the body of usenet postings to find working e-mail-addresses?
>>
>> I do, and I think I've proved it. I put an email address like this:
>>
>> spamsucks.f1d2d2f924e986a...@burditt.org
>>
>> into the body of a USENET post, and scan the server logs for that
>> address after a few days. I don't ALWAYS get email at an address
>> lik that, but it happens sometimes. I've seen spams with such an
>> address show up even after a few years from the one time I put that
>> address in a post. The chance of a spammer guessing that long mess
>> of hex digits is a lot less than spammers extracting email addresses
>> from USENET posts (and, for that matter, from HTML on web sites).
>
> I stand corrected. But I believe this is fetched from websites who
> provide usenet archives (Google groups etc.) and of not via NNTP.

It doesn't matter where it's fetched from or what protocol is used.
It's rude to expose someone else's email address unmunged with
intent to get them spammed, or even with reckless disregard for
whether they get spammed or not.

I think you might be able to prove whether the spammers are getting
it via NNTP if you could find a newsgroup that is not archived.
I'm going to suggest iadfw.* as a possibility. Or do those archive
sites archive *everything*?

If it was posted on USENET, and ended up in a USENET archive, it's
a USENET message, regardless of whether it later gets bounced off
Uranus, goes through a Braille-to-smoke-signal gateway, or makes
part of the trip via carrier dolphins, or even gets fetched via
HTTP(S). (It used to be that news was carried by UUCP, not NNTP).

I do know that some people used their mail reader to read USENET
news because they had asked for a news-to-email gateway built into
things like BNEWS, CNEWS, or INEWS to be activated, sending via
SMTP to their personal email address. (Mostly because they couldn't
figure out how to use a news reader.) This was decades ago, and
with very limited groups, as the volume of a full feed even then
would overwhem anyone trying to read it. This also had the effect
that someone posting to USENET in the subscribed groups might get
a "mailbox full" SMTP bounce from the mailbox owner's ISP if the
owner didn't delete messages fast enough and if the gateway didn't
fix the headers to prevent that.

To make this remotely relevant to PHP, I do recall someone clever
wrote a cute PHP page that would serve up web pages with random
text, random links, and random mailto: links that pointed at a
honeypot mail server specified by the person installing the software.

If you expected this to follow a normal filesystem hierarchy, well,
you soon discovered that it actually had infinite depth. A web
crawler doing depth-first descent ended up with a URL like
http://my.example.com/honeypot/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/page.php
. Actually it just responded to *ANY* URL under a specific directory
and used relative links 1 directory level lower. The code came
with instructions to exclude that directory in robots.txt so Google's
and other legitimate web crawlers wouldn't get stuck in an infinite
loop. Those obey robots.txt; spammers, at least most of them,
don't.

Arno Welzel

unread,

Nov 11, 2015, 1:46:36 AM11/11/15

to

Gordon Burditt schrieb am 2015-11-11 um 06:42:

>>>> You take yourself way too seriously. You really believe spammers will
>>>> scan the body of usenet postings to find working e-mail-addresses?
>>>
>>> I do, and I think I've proved it. I put an email address like this:
>>>
>>> spamsucks.f1d2d2f924e986a...@burditt.org
>>>
>>> into the body of a USENET post, and scan the server logs for that
>>> address after a few days. I don't ALWAYS get email at an address
>>> lik that, but it happens sometimes. I've seen spams with such an
>>> address show up even after a few years from the one time I put that
>>> address in a post. The chance of a spammer guessing that long mess
>>> of hex digits is a lot less than spammers extracting email addresses
>>> from USENET posts (and, for that matter, from HTML on web sites).
>>
>> I stand corrected. But I believe this is fetched from websites who
>> provide usenet archives (Google groups etc.) and of not via NNTP.
>
> It doesn't matter where it's fetched from or what protocol is used.
> It's rude to expose someone else's email address unmunged with
> intent to get them spammed, or even with reckless disregard for
> whether they get spammed or not.

It's even more rude to use munged addresses.

See:

<http://www.interhack.net/pubs/munging-harmful/>
<https://en.wikipedia.org/wiki/Address_munging>
<https://woozle.org/~neale/papers/reply-to-still-harmful.html>

Spam is something we all have to deal with and address munging instead
of a working spam filter just dumps the problem to others who will then
get the NDRs caused by the invalid address etc..

BTW: use...@arnowelzel.de is valid and will be read. And spam to this
address is way less than to other addresses I don't use for usenet postings.

> To make this remotely relevant to PHP, I do recall someone clever
> wrote a cute PHP page that would serve up web pages with random
> text, random links, and random mailto: links that pointed at a
> honeypot mail server specified by the person installing the software.
>
> If you expected this to follow a normal filesystem hierarchy, well,
> you soon discovered that it actually had infinite depth. A web
> crawler doing depth-first descent ended up with a URL like
> http://my.example.com/honeypot/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/page.php
> . Actually it just responded to *ANY* URL under a specific directory
> and used relative links 1 directory level lower. The code came
> with instructions to exclude that directory in robots.txt so Google's
> and other legitimate web crawlers wouldn't get stuck in an infinite
> loop. Those obey robots.txt; spammers, at least most of them,
> don't.

Nice idea.