php-general Digest 2 Mar 2013 12:03:25 -0000 Issue 8144
Topics (messages 320343 through 320354):
Re: Introduction ... !
320343 by: tamouse mailing lists
320348 by: Nick Whiting
320350 by: Jilal Oussama
Re: Holding "datetimes" in a DB.
320344 by: tamouse mailing lists
320345 by: Sebastian Krebs
320347 by: Nick Whiting
320349 by: Paul McGarry
320351 by: Lester Caine
Re: Finding an Address
320346 by: Tedd Sperling
Joining fixed text to a SUBJECT variable
320352 by: Michael CALDER
320353 by: Lester Caine
320354 by: Maciek Sokolewicz
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 ---
On Fri, Mar 1, 2013 at 11:56 AM, Daniel Brown <danbr...@php.net> wrote:
> On Fri, Mar 1, 2013 at 12:54 PM, Jim Giner <jim.gi...@albanyhandball.com>
> wrote:
>>
>> What gives you such optimism? I recently saw a list of languages in use and
>> PHP has dropped quite a bit over the last 5 or more years.
>> Being a relative newbie myself, I'm happy that PHP exists and is so readily
>> available to us hobbyists, etc. Certainly am in favor of your optimism, but
>> curious (hey it's Friday!) about your prediction.
>
> Just knowing how the patterns go. It's always the same, and it
> will likely be the same again. No guarantees, but all it takes is a
> bit of fostering of the community to return it to a decently-vibrant
> forum.
>
> --
> </Daniel P. Brown>
> Network Infrastructure Manager
> http://www.php.net/
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
Things come, things go, ebb and flow. PHP is easy for people to pick
on, for some good and not so good reasons. It, to me, is still the
easiest programming language for someone to learn, in *NO* small
reason because of all the excellent documentation and community
contributed comments. And places like this list.
I've been working in Rails for the past several months, and although I
much prefer Ruby as a language, the documentation on libraries,
extensions, packages, and frameworks is rather lacking. The ruby doc
website has the space for users to add comments, but there's hardly
any.
--- End Message ---
--- Begin Message ---
On Fri, Mar 1, 2013 at 6:32 PM, tamouse mailing lists <
tamouse.li...@gmail.com> wrote:
> On Fri, Mar 1, 2013 at 11:56 AM, Daniel Brown <danbr...@php.net> wrote:
> > On Fri, Mar 1, 2013 at 12:54 PM, Jim Giner <jim.gi...@albanyhandball.com>
> wrote:
> >>
> >> What gives you such optimism? I recently saw a list of languages in
> use and
> >> PHP has dropped quite a bit over the last 5 or more years.
> >> Being a relative newbie myself, I'm happy that PHP exists and is so
> readily
> >> available to us hobbyists, etc. Certainly am in favor of your
> optimism, but
> >> curious (hey it's Friday!) about your prediction.
> >
> > Just knowing how the patterns go. It's always the same, and it
> > will likely be the same again. No guarantees, but all it takes is a
> > bit of fostering of the community to return it to a decently-vibrant
> > forum.
> >
> > --
> > </Daniel P. Brown>
> > Network Infrastructure Manager
> > http://www.php.net/
> >
> > --
> > PHP General Mailing List (http://www.php.net/)
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
>
> Things come, things go, ebb and flow. PHP is easy for people to pick
> on, for some good and not so good reasons. It, to me, is still the
> easiest programming language for someone to learn, in *NO* small
> reason because of all the excellent documentation and community
> contributed comments. And places like this list.
>
> I've been working in Rails for the past several months, and although I
> much prefer Ruby as a language, the documentation on libraries,
> extensions, packages, and frameworks is rather lacking. The ruby doc
> website has the space for users to add comments, but there's hardly
> any.
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
> --
> <http://www.php.net/unsub.php>
> Nickolas Whiting - <http://www.php.net/unsub.php>prggmr.org
> - Remember to write less code that does more faster -
>
One would think with such a widely used language the mailing list would be
crazy ... then again sites such as SO seem to be taking the internet world
by storm and moving what some would call *old school* forums such as this
into the dark.
That said ... it never occurred to me until just recently to get into this
forum, in-fact for a number of years I simply didn't know this forum
existed.
--- End Message ---
--- Begin Message ---
I am new too here (no more than a week)
On Mar 2, 2013 1:37 AM, "Nick Whiting" <prg...@gmail.com> wrote:
> On Fri, Mar 1, 2013 at 6:32 PM, tamouse mailing lists <
> tamouse.li...@gmail.com> wrote:
>
> > On Fri, Mar 1, 2013 at 11:56 AM, Daniel Brown <danbr...@php.net> wrote:
> > > On Fri, Mar 1, 2013 at 12:54 PM, Jim Giner <
> jim.gi...@albanyhandball.com>
> > wrote:
> > >>
> > >> What gives you such optimism? I recently saw a list of languages in
> > use and
> > >> PHP has dropped quite a bit over the last 5 or more years.
> > >> Being a relative newbie myself, I'm happy that PHP exists and is so
> > readily
> > >> available to us hobbyists, etc. Certainly am in favor of your
> > optimism, but
> > >> curious (hey it's Friday!) about your prediction.
> > >
> > > Just knowing how the patterns go. It's always the same, and it
> > > will likely be the same again. No guarantees, but all it takes is a
> > > bit of fostering of the community to return it to a decently-vibrant
> > > forum.
> > >
> > > --
> > > </Daniel P. Brown>
> > > Network Infrastructure Manager
> > > http://www.php.net/
> > >
> > > --
> > > PHP General Mailing List (http://www.php.net/)
> > > To unsubscribe, visit: http://www.php.net/unsub.php
> > >
> >
> > Things come, things go, ebb and flow. PHP is easy for people to pick
> > on, for some good and not so good reasons. It, to me, is still the
> > easiest programming language for someone to learn, in *NO* small
> > reason because of all the excellent documentation and community
> > contributed comments. And places like this list.
> >
> > I've been working in Rails for the past several months, and although I
> > much prefer Ruby as a language, the documentation on libraries,
> > extensions, packages, and frameworks is rather lacking. The ruby doc
> > website has the space for users to add comments, but there's hardly
> > any.
> >
> > --
> > PHP General Mailing List (http://www.php.net/)
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> > --
> > <http://www.php.net/unsub.php>
> > Nickolas Whiting - <http://www.php.net/unsub.php>prggmr.org
> > - Remember to write less code that does more faster -
> >
>
> One would think with such a widely used language the mailing list would be
> crazy ... then again sites such as SO seem to be taking the internet world
> by storm and moving what some would call *old school* forums such as this
> into the dark.
>
> That said ... it never occurred to me until just recently to get into this
> forum, in-fact for a number of years I simply didn't know this forum
> existed.
>
--- End Message ---
--- Begin Message ---
On Fri, Mar 1, 2013 at 11:53 AM, Matijn Woudt <tijn...@gmail.com> wrote:
> On Fri, Mar 1, 2013 at 11:49 AM, Richard Quadling <rquadl...@gmail.com>wrote:
>
>> Hi.
>>
>> My heads trying to remember something I may or may not have known to start
>> with.
>>
>> If I hold datetimes in a DB in UTC and can represent a date to a user
>> based upon a user preference Timezone (not an offset, but a real
>> timezone : Europe/Berlin, etc.) am I missing anything?
>>
>> Richard.
>>
>
> I would only use this if you're planning to have servers all around the
> world in different timezones, then it would be easier to interchange data.
> Otherwise, stick with ur local timezone and it will save you a lot of
> unneeded timezone conversions probably.
>
> - Matijn
This may be just me, but I've always preferred my servers, database,
and such to run UTC, and let users select their own time zone they'd
like to see.
--- End Message ---
--- Begin Message ---
2013/3/2 tamouse mailing lists <tamouse.li...@gmail.com>
> On Fri, Mar 1, 2013 at 11:53 AM, Matijn Woudt <tijn...@gmail.com> wrote:
> > On Fri, Mar 1, 2013 at 11:49 AM, Richard Quadling <rquadl...@gmail.com
> >wrote:
> >
> >> Hi.
> >>
> >> My heads trying to remember something I may or may not have known to
> start
> >> with.
> >>
> >> If I hold datetimes in a DB in UTC and can represent a date to a user
> >> based upon a user preference Timezone (not an offset, but a real
> >> timezone : Europe/Berlin, etc.) am I missing anything?
> >>
> >> Richard.
> >>
> >
> > I would only use this if you're planning to have servers all around the
> > world in different timezones, then it would be easier to interchange
> data.
> > Otherwise, stick with ur local timezone and it will save you a lot of
> > unneeded timezone conversions probably.
> >
> > - Matijn
>
> This may be just me, but I've always preferred my servers, database,
> and such to run UTC, and let users select their own time zone they'd
> like to see.
>
Well, imo it depends ;) There are cases, where it is interesting to know,
when from the users point of view they have created the entity (like a blog
post, a comment, or something like that). The TZ is part of the data and
converting it silently to UTC is always data-loss. So in most cases it is
OK, but not in every :) You can still convert from entity-TZ to UTC to
user-TZ later. Its just one additional step.
Regards,
Sebastian
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
github.com/KingCrunch
--- End Message ---
--- Begin Message ---
On Fri, Mar 1, 2013 at 7:04 PM, Sebastian Krebs <krebs....@gmail.com> wrote:
> 2013/3/2 tamouse mailing lists <tamouse.li...@gmail.com>
>
> > On Fri, Mar 1, 2013 at 11:53 AM, Matijn Woudt <tijn...@gmail.com> wrote:
> > > On Fri, Mar 1, 2013 at 11:49 AM, Richard Quadling <rquadl...@gmail.com
> > >wrote:
> > >
> > >> Hi.
> > >>
> > >> My heads trying to remember something I may or may not have known to
> > start
> > >> with.
> > >>
> > >> If I hold datetimes in a DB in UTC and can represent a date to a user
> > >> based upon a user preference Timezone (not an offset, but a real
> > >> timezone : Europe/Berlin, etc.) am I missing anything?
> > >>
> > >> Richard.
> > >>
> > >
> > > I would only use this if you're planning to have servers all around the
> > > world in different timezones, then it would be easier to interchange
> > data.
> > > Otherwise, stick with ur local timezone and it will save you a lot of
> > > unneeded timezone conversions probably.
> > >
> > > - Matijn
> >
> > This may be just me, but I've always preferred my servers, database,
> > and such to run UTC, and let users select their own time zone they'd
> > like to see.
> >
>
> Well, imo it depends ;) There are cases, where it is interesting to know,
> when from the users point of view they have created the entity (like a blog
> post, a comment, or something like that). The TZ is part of the data and
> converting it silently to UTC is always data-loss. So in most cases it is
> OK, but not in every :) You can still convert from entity-TZ to UTC to
> user-TZ later. Its just one additional step.
>
> Regards,
> Sebastian
>
>
> >
> > --
> > PHP General Mailing List (http://www.php.net/)
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>
>
> --
> github.com/KingCrunch
>
I have found that it's always best to stick to UTC ... regardless of
anything else ... since saving the users local and going to and from can
easily be wrapped into a single entry/exit function and I've had to many
instances where it was saved as local and it came back to bite simply to
save a few minutes.
That said this is something I feel should be documented since for many
newcomers they usually don't think about timezones until it becomes a
problem ...
Cheers!
--
Nickolas Whiting - prggmr.org
- Remember to write less code that does more faster -
--- End Message ---
--- Begin Message ---
On Fri, Mar 1, 2013 at 9:49 PM, Richard Quadling <rquadl...@gmail.com> wrote:
> Hi.
>
> My heads trying to remember something I may or may not have known to start
> with.
>
> If I hold datetimes in a DB in UTC and can represent a date to a user
> based upon a user preference Timezone (not an offset, but a real
> timezone : Europe/Berlin, etc.) am I missing anything?
Perhaps the "best" alternative is to store the data in the DB in a
datatype that includes timezone, eg "timestamp with timezone"
http://www.postgresql.org/docs/9.1/static/datatype-datetime.html
That way you can let the DB take care of any conversions when you need
it, ie you can insert using Europe/Berlin and then select using UTC
(etc etc).
If you are just quickly writing your app for one timezone you can have
that as the 'default' but then if you want to expand later then all
your data is already in the most useful format.
Paul
Paul
--- End Message ---
--- Begin Message ---
Paul McGarry wrote:
My heads trying to remember something I may or may not have known to start with.
>
>If I hold datetimes in a DB in UTC and can represent a date to a user
>based upon a user preference Timezone (not an offset, but a real
>timezone : Europe/Berlin, etc.) am I missing anything?
Perhaps the "best" alternative is to store the data in the DB in a
datatype that includes timezone, eg "timestamp with timezone"
http://www.postgresql.org/docs/9.1/static/datatype-datetime.html
That way you can let the DB take care of any conversions when you need
it, ie you can insert using Europe/Berlin and then select using UTC
(etc etc).
If you are just quickly writing your app for one timezone you can have
that as the 'default' but then if you want to expand later then all
your data is already in the most useful format.
The only clean way of doing any of this is NOT to bundle an offset in with the
time. Simply because that offset has EXACTLY the same problem as the simplistic
time offset provided by the browser. Can we move that meeting to the same time
next week can result in an hours error? Even the current timezone abbreviations
are not totally consistent, only a clean timezone/daylight saving will give the
real time around a change in daylight saving! UTC is a constant, and a proper
TZ/DS for the client location completes the picture.
Running the underlying server on anything other than UTC simply doubles the
chance of problems if there are four differences between the server and client
time zones, but what is NEEDED is that the client browser returns a client
timezone rather than a simple offset!
--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
--- End Message ---
--- Begin Message ---
On Feb 28, 2013, at 12:36 PM, Floyd Resler <fres...@adex-intl.com> wrote:
> I have a project where my client would like to find the nearest street
> address from where he current is. Getting the longitude and latitude is easy
> enough but I'm having a hard time finding out how to get the nearest house.
> I have found a lot of solutions for addresses maintained in a database but
> these addresses won't be in a database. I thought about just querying Google
> for each longitude and latitude within in a small circle but my math skills
> are nowhere near good enough to accomplish that. Anyone have any ideas?
>
> Thanks!
> Floyd
What about using zip codes?
Like so:
http://php1.net/a/zipcode/
Cheers,
tedd
_____________________
t...@sperling.com
http://sperling.com
--- End Message ---
--- Begin Message ---
-- G'day ,
I have a basically simple problem the solution to which has eluded me
for several days.
I have a form being handled by a .php file.
I want the received email sent by the form to have as its SUBJECT the
combination of the form name "RVRA Contact Form - " and the MESSAGE
SUBJECT as chosen in the form drop down box.
Here is the current contact2.php file - but the SUBJECT only shows as
RVRA Contact Form -
<?php
// get posted data into local variables
$EmailAddress = Trim(stripslashes($_POST['EmailAddress']));
$EmailTo = "mikecal...@optusnet.com.au";
$Subject = "RVRA Contact Form - ,$MessageSubject";
$Name = Trim(stripslashes($_POST['Name']));
$EmailAddress = Trim(stripslashes($_POST['EmailAddress']));
$YesNo = Trim(stripslashes($_POST['YesNo']));
$MessageSubject = Trim(stripslashes($_POST['MessageSubject']));
$Message = Trim(stripslashes($_POST['Message']));
// send email
if(!isset($_REQUEST['identiPIC_selected'])){exit;}
$identiPIC[1] = "Bird";
$identiPIC[2] = "Logo";
$identiPIC[3] = "Flower";
if($_REQUEST['identiPIC_selected'] !== $identiPIC){print "<meta
http-equiv=\"refresh\" content=\"0;URL=error-pic.html\">"; exit;}
// prepare email body text
$Body = "";
$Body .= "Name: ";
$Body .= $Name;
$Body .= "\n";
$Body .= "EmailAddress: ";
$Body .= $EmailAddress;
$Body .= "\n";
$Body .= "RVRA Member";
$Body .= $YesNo;
$Body .= "\n";
$Body .= "Message Subject: ";
$Body .= $MessageSubject;
$Body .= "\n";
$Body .= "Message: ";
$Body .= $Message;
$Body .= "\n";
// send email
$success = mail($EmailTo, $Subject, $Body, "From: <$EmailAddress>");
// redirect to success page
if ($success){
print "<meta http-equiv=\"refresh\" content=\"0;URL=thanks.html\">";
}
else{
print "<meta http-equiv=\"refresh\" content=\"0;URL=error-pic.html\">";
}
?>
The critical line is line 4:
$Subject = "RVRA Contact Form - ,$MessageSubject";
Can anyone please advise or point me in the right direction for
instructions on how to combine the fixed text with the variable
$MessageSubject.
Thanks....
Mike
Michael CALDER
73/81 Willandra Road,
CROMER NSW 2099
02 9981 6327
--- End Message ---
--- Begin Message ---
Michael CALDER wrote:
$Subject = "RVRA Contact Form - ,$MessageSubject";
Can anyone please advise or point me in the right direction for
instructions on how to combine the fixed text with the variable
$MessageSubject.
The quick fix is simply
$Subject = "RVRA Contact Form - ".$MessageSubject;
but
$Subject = "RVRA Contact Form - ,$MessageSubject";
should work, what is the error? ... you don't actually want the ','
$Subject = "RVRA Contact Form - $MessageSubject";
Should work as well
--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
--- End Message ---
--- Begin Message ---
On 2-3-2013 12:23, Lester Caine wrote:
Michael CALDER wrote:
$Subject = "RVRA Contact Form - ,$MessageSubject";
Can anyone please advise or point me in the right direction for
instructions on how to combine the fixed text with the variable
$MessageSubject.
The quick fix is simply
$Subject = "RVRA Contact Form - ".$MessageSubject;
but
$Subject = "RVRA Contact Form - ,$MessageSubject";
should work, what is the error? ... you don't actually want the ','
$Subject = "RVRA Contact Form - $MessageSubject";
Should work as well
No it shouldn't, unless you have register_globals turned On. Which most
hosts don't (and shouldn't) do.
The problem is the simple fact that the variable $MessageSubject is not
defined until 4 lines farther into the script. Changing the variable to
$_POST['MessageSubject'] (and concatenating using the concatenation
operator (the period: '.' )) should fix this for you.
If Michael had E_NOTICE errors turned on, he would see an E_NOTICE:
"Undefined variable" on line 6. Apparently, he doesn't show E_NOTICEs
either.
--- End Message ---
