php-general Digest 10 Mar 2012 03:20:00 -0000 Issue 7720
Topics (messages 316950 through 316961):
Re: Function mktime() documentation question
316950 by: Daniel Brown
316951 by: Tedd Sperling
316952 by: Charles
316953 by: Tedd Sperling
316954 by: Charles
316955 by: Andrew Ballard
316956 by: Charles
316957 by: Ashley Sheridan
316958 by: Charles
316959 by: Tedd Sperling
Re: questions about $_SERVER
316960 by: tamouse mailing lists
316961 by: Jim Giner
Administrivia:
To subscribe to the digest, e-mail:
php-general-digest-subscr...@lists.php.net
To unsubscribe from the digest, e-mail:
php-general-digest-unsubscr...@lists.php.net
To post to the list, e-mail:
php-gene...@lists.php.net
----------------------------------------------------------------------
--- Begin Message ---
(To the list, as well. First day with my new fingers, apparently....)
On Fri, Mar 9, 2012 at 08:09, Daniel Brown <danbr...@php.net> wrote:
> On Thu, Mar 8, 2012 at 21:23, Tedd Sperling <tedd.sperl...@gmail.com> wrote:
>
> This starts getting a bit off-topic from your original email, but
> knowing that you're trying to use it for teaching your classes at the
> college, it may be of some value to you.
>
>>> All of this aside, though, you may instead want to use something along the
>>> lines of date('d',strtotime('last day of this month')); in tandem with your
>>> date formatting.
>>
>> That's a good idea, but
>>
>>> date('d',strtotime('last day of this month'));
>>
>> gives me the number of days in *this* month, but not the next, or previous,
>> month.
>>
>> I need the result to be whatever date was selected -- something like:
>>
>> $number_days = date('d',strtotime('last day of April, 2014'));
>>
>> But that doesn't work.
>
> Sure it does, though you may have some issues when using
> punctuation, unnecessary words, or using capital letters for anything
> other than proper names. What version of PHP are you using? I get
> the correct answers for all of the following phrases:
>
> "last day of April 2014"
> "last day of this month"
> "last day of next month"
> "last day of last month"
> "third Saturday March 2012"
>
> Or you can even be excruciatingly redundant:
>
> echo date('d',strtotime('last day of this
> month',strtotime('next month')));
> echo date('d',strtotime('last day of this
> month',strtotime('February 2018')));
> echo date('d',strtotime('second Monday',strtotime('September 2012')));
>
> --
> </Daniel P. Brown>
> Network Infrastructure Manager
> http://www.php.net/
--
</Daniel P. Brown>
Network Infrastructure Manager
http://www.php.net/
--- End Message ---
--- Begin Message ---
On Mar 9, 2012, at 5:37 AM, Ford, Mike wrote:
>> From: Tedd Sperling [mailto:tedd.sperl...@gmail.com]
>> But why does anyone have to use the next month to figure out how
>> many days there are are in this month? Do you see my point?
>
> Actually, no. To figure this out, somewhere along the line you've
> got to know where the last day of this month / first day of next
> month boundary lies, so I don't see how you can ever find the number
> of days in a month without bringing the start of next month into it
> somehow. (Even if it's implicitly be getting someone else's clever
> code to figure out 'last day of this month'!)
Well no, I don't need to know the first day of next month to know the last day
of this month. That's like saying "I need to know who is going to stand at the
'end of the line' NEXT before I can tell who is standing at the 'end of the'
line NOW."
I like things to be self-contained. For the exception of multiverse arguments,
everything should be self evident.
>> But instead, we have to use:
>>
>> $next_month = $this_month +1;
>> $what_date = getdate(mktime(0, 0, 0, $next_month, 0, $year));
>> $days_in_this_month = $what_date['mday'];
>
> To me, that's a clever and elegant solution. It's clear that our
> brains just work differently on this one.
We all have differences in perception, how we analyze problems, and how we
create solutions -- and that's a good thing.
> Side-point: I find it interesting that getdate() has all sorts of
>> neat descriptions for the current month (such as, what weekday a
>> numbered day is), but lacks how many days are in the month. Doesn't
>> that seem odd?
>
> Now that's a decent point: I can see where you're coming from with that
> one. I don't know what performance penalty there might be (if any) to
> calculate that for every call to getdate(), but it certainly seems like
> a reasonable feature request.
I'm glad I have a decent point somewhere in this exchange and that we agree on
something. :-)
Cheers,
tedd
_____________________
tedd.sperl...@gmail.com
http://sperling.com
--- End Message ---
--- Begin Message ---
On Fri, Mar 9, 2012 at 10:58 PM, Tedd Sperling <tedd.sperl...@gmail.com> wrote:
> On Mar 9, 2012, at 5:37 AM, Ford, Mike wrote:
>>> From: Tedd Sperling [mailto:tedd.sperl...@gmail.com]
>>> But why does anyone have to use the next month to figure out how
>>> many days there are are in this month? Do you see my point?
>>
>> Actually, no. To figure this out, somewhere along the line you've
>> got to know where the last day of this month / first day of next
>> month boundary lies, so I don't see how you can ever find the number
>> of days in a month without bringing the start of next month into it
>> somehow. (Even if it's implicitly be getting someone else's clever
>> code to figure out 'last day of this month'!)
>
> Well no, I don't need to know the first day of next month to know the last
> day of this month. That's like saying "I need to know who is going to stand
> at the 'end of the line' NEXT before I can tell who is standing at the 'end
> of the' line NOW."
The number of days in each month is fixed, except for february. If
that's what you want, why don't make a table of the number of days in
each month, and check for the special case of leap year.
--- End Message ---
--- Begin Message ---
On Mar 9, 2012, at 11:17 AM, Charles wrote:
> On Fri, Mar 9, 2012 at 10:58 PM, Tedd Sperling <tedd.sperl...@gmail.com>
> wrote:
>> On Mar 9, 2012, at 5:37 AM, Ford, Mike wrote:
>>>> From: Tedd Sperling [mailto:tedd.sperl...@gmail.com]
>>>> But why does anyone have to use the next month to figure out how
>>>> many days there are are in this month? Do you see my point?
>>>
>>> Actually, no. To figure this out, somewhere along the line you've
>>> got to know where the last day of this month / first day of next
>>> month boundary lies, so I don't see how you can ever find the number
>>> of days in a month without bringing the start of next month into it
>>> somehow. (Even if it's implicitly be getting someone else's clever
>>> code to figure out 'last day of this month'!)
>>
>> Well no, I don't need to know the first day of next month to know the last
>> day of this month. That's like saying "I need to know who is going to stand
>> at the 'end of the line' NEXT before I can tell who is standing at the 'end
>> of the' line NOW."
>
> The number of days in each month is fixed, except for february. If
> that's what you want, why don't make a table of the number of days in
> each month, and check for the special case of leap year.
No offense, but that's not the point. A look-up table would work, but why when
there are all sorts of built-in functions that will?
I am just looking for one that is easy to explain to students.
Cheers,
tedd
_____________________
tedd.sperl...@gmail.com
http://sperling.com
--- End Message ---
--- Begin Message ---
On Sat, Mar 10, 2012 at 12:07 AM, Tedd Sperling <tedd.sperl...@gmail.com> wrote:
> On Mar 9, 2012, at 11:17 AM, Charles wrote:
>
>> On Fri, Mar 9, 2012 at 10:58 PM, Tedd Sperling <tedd.sperl...@gmail.com>
>> wrote:
>>> On Mar 9, 2012, at 5:37 AM, Ford, Mike wrote:
>>>>> From: Tedd Sperling [mailto:tedd.sperl...@gmail.com]
>>>>> But why does anyone have to use the next month to figure out how
>>>>> many days there are are in this month? Do you see my point?
>>>>
>>>> Actually, no. To figure this out, somewhere along the line you've
>>>> got to know where the last day of this month / first day of next
>>>> month boundary lies, so I don't see how you can ever find the number
>>>> of days in a month without bringing the start of next month into it
>>>> somehow. (Even if it's implicitly be getting someone else's clever
>>>> code to figure out 'last day of this month'!)
>>>
>>> Well no, I don't need to know the first day of next month to know the last
>>> day of this month. That's like saying "I need to know who is going to stand
>>> at the 'end of the line' NEXT before I can tell who is standing at the 'end
>>> of the' line NOW."
>>
>> The number of days in each month is fixed, except for february. If
>> that's what you want, why don't make a table of the number of days in
>> each month, and check for the special case of leap year.
>
> No offense, but that's not the point. A look-up table would work, but why
> when there are all sorts of built-in functions that will?
You just said yourself that "I don't need to know the first day of
next month to know the last day of this month", and AFAIK there is no
such function in PHP to get the number of days
without accessing the last second in the month. Besides, showing how
it is done is part of education.
--- End Message ---
--- Begin Message ---
And again to the list, since for some reason "Reply-to-all" did not do
as intended this time.
---------- Forwarded message ----------
From: Andrew Ballard <aball...@gmail.com>
Date: Fri, Mar 9, 2012 at 12:53 PM
Subject: Re: [PHP] Function mktime() documentation question
To: Tedd Sperling <tedd.sperl...@gmail.com>
On Fri, Mar 9, 2012 at 12:07 PM, Tedd Sperling <tedd.sperl...@gmail.com> wrote:
[snip]
> I am just looking for one that is easy to explain to students.
>
> Cheers,
>
> tedd
tedd,
Since you are teaching this to students, I would recommend sticking
with the internal date functions and avoiding any solution that
includes adding or subtracting multiples of the magic number 86400.*
Many such "solutions" fail to take into consideration Daylight Saving
Time and are therefore guaranteed to be wrong at least twice a year
(if not several months out of the year). Sure, you can write your code
to handle the differences correctly, but since the rules governing the
time shift are mostly arbitrary and differ across time zones the world
over, it seems safer to me to rely on the internal functions when
working with dates.
Andrew
* Even if the internal functions base their calculations on the number
of seconds per day, they have at least already handled all the varied
time zones and DST rules and been tested in environments all over the
world. When those rules change, the internal functions will be
adjusted to reflect the changes and should be much more reliable than
thousands of instances of multiple strategies that get copied and
pasted into projects.
--- End Message ---
--- Begin Message ---
On Sat, Mar 10, 2012 at 12:52 AM, Charles <peac...@gmail.com> wrote:
> On Sat, Mar 10, 2012 at 12:07 AM, Tedd Sperling <tedd.sperl...@gmail.com>
> wrote:
>> On Mar 9, 2012, at 11:17 AM, Charles wrote:
>>
>>> On Fri, Mar 9, 2012 at 10:58 PM, Tedd Sperling <tedd.sperl...@gmail.com>
>>> wrote:
>>>> On Mar 9, 2012, at 5:37 AM, Ford, Mike wrote:
>>>>>> From: Tedd Sperling [mailto:tedd.sperl...@gmail.com]
>>>>>> But why does anyone have to use the next month to figure out how
>>>>>> many days there are are in this month? Do you see my point?
>>>>>
>>>>> Actually, no. To figure this out, somewhere along the line you've
>>>>> got to know where the last day of this month / first day of next
>>>>> month boundary lies, so I don't see how you can ever find the number
>>>>> of days in a month without bringing the start of next month into it
>>>>> somehow. (Even if it's implicitly be getting someone else's clever
>>>>> code to figure out 'last day of this month'!)
>>>>
>>>> Well no, I don't need to know the first day of next month to know the last
>>>> day of this month. That's like saying "I need to know who is going to
>>>> stand at the 'end of the line' NEXT before I can tell who is standing at
>>>> the 'end of the' line NOW."
>>>
>>> The number of days in each month is fixed, except for february. If
>>> that's what you want, why don't make a table of the number of days in
>>> each month, and check for the special case of leap year.
>>
>> No offense, but that's not the point. A look-up table would work, but why
>> when there are all sorts of built-in functions that will?
>
> You just said yourself that "I don't need to know the first day of
> next month to know the last day of this month", and AFAIK there is no
> such function in PHP to get the number of days
> without accessing the last second in the month. Besides, showing how
> it is done is part of education.
Unless, of course you install the "calendar" extension, of which it
will provides just the required function
http://php.net/manual/en/function.cal-days-in-month.php
--- End Message ---
--- Begin Message ---
Charles <peac...@gmail.com> wrote:
>On Sat, Mar 10, 2012 at 12:52 AM, Charles <peac...@gmail.com> wrote:
>> On Sat, Mar 10, 2012 at 12:07 AM, Tedd Sperling
><tedd.sperl...@gmail.com> wrote:
>>> On Mar 9, 2012, at 11:17 AM, Charles wrote:
>>>
>>>> On Fri, Mar 9, 2012 at 10:58 PM, Tedd Sperling
><tedd.sperl...@gmail.com> wrote:
>>>>> On Mar 9, 2012, at 5:37 AM, Ford, Mike wrote:
>>>>>>> From: Tedd Sperling [mailto:tedd.sperl...@gmail.com]
>>>>>>> But why does anyone have to use the next month to figure out how
>>>>>>> many days there are are in this month? Do you see my point?
>>>>>>
>>>>>> Actually, no. To figure this out, somewhere along the line you've
>>>>>> got to know where the last day of this month / first day of next
>>>>>> month boundary lies, so I don't see how you can ever find the
>number
>>>>>> of days in a month without bringing the start of next month into
>it
>>>>>> somehow. (Even if it's implicitly be getting someone else's
>clever
>>>>>> code to figure out 'last day of this month'!)
>>>>>
>>>>> Well no, I don't need to know the first day of next month to know
>the last day of this month. That's like saying "I need to know who is
>going to stand at the 'end of the line' NEXT before I can tell who is
>standing at the 'end of the' line NOW."
>>>>
>>>> The number of days in each month is fixed, except for february. If
>>>> that's what you want, why don't make a table of the number of days
>in
>>>> each month, and check for the special case of leap year.
>>>
>>> No offense, but that's not the point. A look-up table would work,
>but why when there are all sorts of built-in functions that will?
>>
>> You just said yourself that "I don't need to know the first day of
>> next month to know the last day of this month", and AFAIK there is no
>> such function in PHP to get the number of days
>> without accessing the last second in the month. Besides, showing how
>> it is done is part of education.
>
>Unless, of course you install the "calendar" extension, of which it
>will provides just the required function
>
>http://php.net/manual/en/function.cal-days-in-month.php
>
>--
>PHP General Mailing List (http://www.php.net/)
>To unsubscribe, visit: http://www.php.net/unsub.php
What about just doing this:
intval(date("t"));
And you can pass in an argument to date() if you need a specific month.
Thanks,
Ash
http://ashleysheridan.co.uk
--- End Message ---
--- Begin Message ---
On Sat, Mar 10, 2012 at 12:57 AM, Charles <peac...@gmail.com> wrote:
> On Sat, Mar 10, 2012 at 12:52 AM, Charles <peac...@gmail.com> wrote:
>> On Sat, Mar 10, 2012 at 12:07 AM, Tedd Sperling <tedd.sperl...@gmail.com>
>> wrote:
>>> On Mar 9, 2012, at 11:17 AM, Charles wrote:
>>>
>>>> On Fri, Mar 9, 2012 at 10:58 PM, Tedd Sperling <tedd.sperl...@gmail.com>
>>>> wrote:
>>>>> On Mar 9, 2012, at 5:37 AM, Ford, Mike wrote:
>>>>>>> From: Tedd Sperling [mailto:tedd.sperl...@gmail.com]
>>>>>>> But why does anyone have to use the next month to figure out how
>>>>>>> many days there are are in this month? Do you see my point?
>>>>>>
>>>>>> Actually, no. To figure this out, somewhere along the line you've
>>>>>> got to know where the last day of this month / first day of next
>>>>>> month boundary lies, so I don't see how you can ever find the number
>>>>>> of days in a month without bringing the start of next month into it
>>>>>> somehow. (Even if it's implicitly be getting someone else's clever
>>>>>> code to figure out 'last day of this month'!)
>>>>>
>>>>> Well no, I don't need to know the first day of next month to know the
>>>>> last day of this month. That's like saying "I need to know who is going
>>>>> to stand at the 'end of the line' NEXT before I can tell who is standing
>>>>> at the 'end of the' line NOW."
>>>>
>>>> The number of days in each month is fixed, except for february. If
>>>> that's what you want, why don't make a table of the number of days in
>>>> each month, and check for the special case of leap year.
>>>
>>> No offense, but that's not the point. A look-up table would work, but why
>>> when there are all sorts of built-in functions that will?
>>
>> You just said yourself that "I don't need to know the first day of
>> next month to know the last day of this month", and AFAIK there is no
>> such function in PHP to get the number of days
>> without accessing the last second in the month. Besides, showing how
>> it is done is part of education.
>
> Unless, of course you install the "calendar" extension, of which it
> will provides just the required function
>
> http://php.net/manual/en/function.cal-days-in-month.php
Okay, scratch that, the standard function works fine
$number_of_days = idate('t', strtotime($year.'-'.$month));
--- End Message ---
--- Begin Message ---
On Mar 9, 2012, at 12:52 PM, Charles wrote:
> On Sat, Mar 10, 2012 at 12:07 AM, Tedd Sperling <tedd.sperl...@gmail.com>
> wrote:
>>
>> Well no, I don't need to know the first day of next month to know the last
>> day of this month. That's like saying "I need to know who is going to stand
>> at the 'end of the line' NEXT before I can tell who is standing at the 'end
>> of the' line NOW."
>
> You just said yourself that "I don't need to know the first day of
> next month to know the last day of this month", and AFAIK there is no
> such function in PHP to get the number of days
> without accessing the last second in the month. Besides, showing how
> it is done is part of education.
Arrggg.
When I said "I, I meant "I" and not a php function.
Sometimes the point is never made.
tedd
_____________________
tedd.sperl...@gmail.com
http://sperling.com
--- End Message ---
--- Begin Message ---
On Mon, Feb 13, 2012 at 2:39 PM, Tedd Sperling <tedd.sperl...@gmail.com> wrote:
> On Feb 13, 2012, at 4:10 AM, Stuart Dallas wrote:
>> On 13 Feb 2012, at 06:28, Rui Hu wrote:
>>> How PHP sets variables in $_SERVER, say, $DOCUMENT_ROOT? What should I know
>>> if I want to modify $_SERVER myself?
>>
>> Once your script starts the superglobals are no different to any other
>> variables, except that they're in scope at all times.
>
> That's probably the reason why they are named "SuperGlobals". :-)
>
> But to be more descriptive, these are simply globals that are predefined by
> php -- see:
>
> http://php.net/manual/en/language.variables.superglobals.php
>
> I believe, (please show me otherwise) there are no "globals" in PHP other
> than SuperGlobals.
Assuming you mean pre-defined ones, there shouldn't be, since no other
ones are documented. If there are, then either they should be
documented, or they should be ignored as it can be dangerous to use
undocumented features. :)
--- End Message ---
--- Begin Message ---
"tamouse mailing lists" <tamouse.li...@gmail.com> wrote in message
news:CAHUC_t8g43GE3xqvSU5SwFePGS1XG=tk1mhrbem9gjaarve...@mail.gmail.com...
> On Mon, Feb 13, 2012 at 2:39 PM, Tedd Sperling <tedd.sperl...@gmail.com>
> wrote:
>> On Feb 13, 2012, at 4:10 AM, Stuart Dallas wrote:
>>> On 13 Feb 2012, at 06:28, Rui Hu wrote:
>>>> How PHP sets variables in $_SERVER, say, $DOCUMENT_ROOT? What should I
>>>> know
>>>> if I want to modify $_SERVER myself?
>>>
>>> Once your script starts the superglobals are no different to any other
>>> variables, except that they're in scope at all times.
>>
>> That's probably the reason why they are named "SuperGlobals". :-)
>>
>> But to be more descriptive, these are simply globals that are predefined
>> by php -- see:
>>
>> http://php.net/manual/en/language.variables.superglobals.php
>>
>> I believe, (please show me otherwise) there are no "globals" in PHP other
>> than SuperGlobals.
>
> Assuming you mean pre-defined ones, there shouldn't be, since no other
> ones are documented. If there are, then either they should be
> documented, or they should be ignored as it can be dangerous to use
> undocumented features. :)
Just to be clear - you asked if it were true that "there are no "globals" in
PHP other than SuperGlobals: Don't forget that anything that you declare as
global in a script is a global for that instance of that script (and
whatever includes, etc. that it calls during its run)
--- End Message ---
