newbee stupid question regarding $initstartdate = date("d-m-Y");

[WindAndWaves]

Hi there

I have

$initstartdate = date("d-m-Y");

in my code

How can I get it to be date() + 1 or 7 for that matter. Because my server is in the US and I am in New Zealand, they are always a
day behind....

I have looked at php.net, I just could not work it out ...

Thank you

- Nicolaas

 

[WindAndWaves]

sorry this one was supposed to go to php group ...


Hi there

I have

$initstartdate = date("d-m-Y");

in my code

How can I get it to be date() + 1 or 7 for that matter. Because my server is in the US and I am in New Zealand, they are always a
day behind....

I have looked at php.net, I just could not work it out ...

Thank you

- Nicolaas

 

[Richard]

sorry this one was supposed to go to php group ...

Hi there

I have

$initstartdate = date("d-m-Y");

in my code

How can I get it to be date() + 1 or 7 for that matter. Because my
server is in the US and I am in New Zealand, they are always a
day behind....

I have looked at php.net, I just could not work it out ...

Thank you

- Nicolaas

While you're working on the script, set your clock to a US time zone.
If you add anything to YOUR script, then those in the US would see it wrong.

 

[WindAndWaves]

While you're working on the script, set your clock to a US time zone.
If you add anything to YOUR script, then those in the US would see it wrong.

Well, Richard, we are in New Zealand and not in the US. We also format the date as mm-dd-yyyy. Furthermore, it is OK to be one day
ahead - it makes sense in context (hotel booking service), but one day in the past looks stupid.

Is there an alternative answer?

Thank you for your reply.

- Nicolaas

 

[Richard]

Well, Richard, we are in New Zealand and not in the US. We also format
the date as mm-dd-yyyy. Furthermore, it is OK to be one day
ahead - it makes sense in context (hotel booking service), but one day
in the past looks stupid.

Is there an alternative answer?

Thank you for your reply.

- Nicolaas

Set it to GMT????

 

[Steve]

Well, Richard, we are in New Zealand and not in the US. We also format the date as mm-dd-yyyy. Furthermore, it is OK to be one day
ahead - it makes sense in context (hotel booking service), but one day in the past looks stupid.

Is there an alternative answer?

Thank you for your reply.

- Nicolaas

So am I and I bl**dy don't. Nor does anyone else I know. dd/mm/yyyy.
However, I agree with the arrogance of any poster demanding we use an US TZ!

To answer the problem that you've got requires javascript to be run on
the client machine to get the time offset. Once you've got that, then
you can offset by using putenv ("TZ=$timezone") to modify the server
timezone to the same value.

That's how I've done it in the past. I save all datestamps in Mysql as
UTC to make life easier as well.


Steve
Proudly GMT+13.

 

[Geoff Berrow]

To answer the problem that you've got requires javascript to be run on
the client machine to get the time offset. Once you've got that, then
you can offset by using putenv ("TZ=$timezone") to modify the server
timezone to the same value.

That's how I've done it in the past. I save all datestamps in Mysql as
UTC to make life easier as well.

The OP just wants to offset the date by a fixed amount to compensate for
the fact that the server is in the States. So he could either add a
known number of seconds to time() or use strtotime()

$timestamp=strtotime(+n hours); //where n is the time difference

$initstartdate = date("d-m-Y",$timestamp);

Not sure how daylight saving would affect that though.

 

[WindAndWaves]

The OP just wants to offset the date by a fixed amount to compensate for
the fact that the server is in the States. So he could either add a
known number of seconds to time() or use strtotime()

$timestamp=strtotime(+n hours); //where n is the time difference

$initstartdate = date("d-m-Y",$timestamp);

Not sure how daylight saving would affect that though.

--
Geoff Berrow (put thecat out to email)
It's only Usenet, no one dies.
My opinions, not the committee's, mine.
Simple RFDs http://www.ckdog.co.uk/rfdmaker/

Hi Guys

Lets not get too pedantic here. I like this timestamp thing, I will just add a couple of hours. In the exciting world of travel
hours a pretty messy anyway and all I wanted to do is to have a feasible start date for a trip (they can change it themselves if
they want to...).

Thanks for all your interesting answers I will

Nicolaas +as many as possible

PS la luche sigue....

 

[Geoff Berrow]

I like this timestamp thing, I will just add a couple of hours. In the exciting world of travel
hours a pretty messy anyway and all I wanted to do is to have a feasible start date for a trip (they can change it themselves if
they want to...).

Pragmatism. I like that.

 

[Sean]

The OP just wants to offset the date by a fixed amount to compensate for
the fact that the server is in the States. So he could either add a
known number of seconds to time() or use strtotime()

$timestamp=strtotime(+n hours); //where n is the time difference

$initstartdate = date("d-m-Y",$timestamp);

Not sure how daylight saving would affect that though.

DST should not affect time() which is measured in seconds since the
Unix epoch. I have not researched this too far since I use servers in
Arizona where DST is never observed (the time is constant). But if
one just used time() and adds hours_offset*3600 to time it will solve
the problem. I would suspect that DST affects date() though.

Also, to a prior poster, Javascript is a poor choice as the
application should no the time zone of each hotel, hence the offset
should be known by the server for each hotel which appears to be only
two time zone for New Zealand.

from: http://www.statoids.com/tnz.html
UTC+12o for NZST
UTC+12:45 for CHAST (the Chatham Islands)

From the first Sunday in October to the third Sunday in March
UTC+13o for NZDT
UTC+13:45 for CHADT

That said, there is plenty of discussion in the PHP manual if you read
the user comments.

http://us3.php.net/manual/en/function.date.php

And of course one should test one's server and check with the system
administrators to get their time maintenance policy.

enjoy,

Sean



"In the End, we will remember not the words of our enemies,
but the silence of our friends."

- Martin Luther King Jr. (1929-1968)

Photo Archive @ http://www.tearnet.com/Sean
Last Updated 29 Sept. 2004

 

[Steve]

DST should not affect time() which is measured in seconds since the
Unix epoch. I have not researched this too far since I use servers in
Arizona where DST is never observed (the time is constant). But if
one just used time() and adds hours_offset*3600 to time it will solve
the problem. I would suspect that DST affects date() though.

Also, to a prior poster, Javascript is a poor choice as the
application should no the time zone of each hotel, hence the offset
should be known by the server for each hotel which appears to be only
two time zone for New Zealand.

Well, if you can suggest another client side language that can pick up
the info, then let me know.

What if you're browsing the website from Peru, for example. All the
times will be wrong.

 

[Sean]

Well, if you can suggest another client side language that can pick up
the info, then let me know.

This is not my issue. My issue is the use of local time when the time
at the destination is the time that fits the problem domain.

What if you're browsing the website from Peru, for example. All the
times will be wrong.

For a hotel reservation at a hotel in New Zealand? I have never heard
of making a hotel reservation in anything but the local time of the
hotel. I am almost certain a hotel clerk in Auckland could care less
what time it is in Peru.

This is not to say using Javascript to localize displayed times in
another application is not a good idea, it just makes no sense to me
in this application.

enjoy,

Sean


"In the End, we will remember not the words of our enemies,
but the silence of our friends."

- Martin Luther King Jr. (1929-1968)

Photo Archive @ http://www.tearnet.com/Sean
Last Updated 29 Sept. 2004

 

[WindAndWaves]

.....

Also, to a prior poster, Javascript is a poor choice as the
application should no the time zone of each hotel, hence the offset
should be known by the server for each hotel which appears to be only
two time zone for New Zealand.

Javascript is a nightmare when it comes to getting the time right, because it is client side and who knows what those clients do
with their clocks. Mine, for example, seems to be out of sink regularly.....

Anyway, most people know what time it is at their place, they would rather know what time it is somewhere else ;-)

Nicolaas

 

[Dr John Stockton]

JRS: In article <[email protected]>, dated
Sun, 30 Jan 2005 10:20:04, seen in Geoff

The OP just wants to offset the date by a fixed amount to compensate for
the fact that the server is in the States. So he could either add a
known number of seconds to time() or use strtotime()

$timestamp=strtotime(+n hours); //where n is the time difference

$initstartdate = date("d-m-Y",$timestamp);

Not sure how daylight saving would affect that though.

As long as you allow "fixed" to mean "changes at least twice a year, and
possibly four times", you see no problem.

The server should be serving time in GMT; to suit the local natives'
whims, it may also serve native civil time. But one should only get GMT
or UTC from a server (UK servers probably serve UTC illegally).

If the OP's users want their local time, their machines can tell them
that, if properly set, which is their responsibility.

If it is necessary to relate civil time at places remote from the user
to UTC, then it is necessary to know the Time Zone and Summer Time Rules
for each remote place, which can be expressed as a TZ string (that may
rule out Israel; JJC?). Then, by careful reading of the FAQ of this
newsgroup, one can see how to convert UTC into remote civil time.

The OP's question is not well expressed; but offsetting a date/time by a
given amount of absolute or civil time is not difficult in javascript,
though frequently done wrongly.

 

[Sean]

....


Javascript is a nightmare when it comes to getting the time right, because
it is client side and who knows what those clients do
with their clocks. Mine, for example, seems to be out of sink regularly.....

Anyway, most people know what time it is at their place, they would
rather know what time it is somewhere else ;-)

)

I agree. Like what time it is at home with your feet up and resting
rather than what time it is at work. ;o)

As for time accuracy, if you run Windows XP, go to Start->Control
Panel and double click "date and time".

Next, go to the "Time Zone" tab and ensure that the checkbox for
"Automatically adjust clock for daylight saving changes" is checked
and that you have the proper time zone selected.

Next, go the "Internet Time" tab and ensure that the checkbox for
"Automatically synchronize with an Internet time server" is checked.
Pick your favorite time server from the drop down list.

Next, forget about keeping the clock on your PC in sync, it will take
care of itself and should remain accurate within a minute or so.

enjoy,

Sean


"In the End, we will remember not the words of our enemies,
but the silence of our friends."

- Martin Luther King Jr. (1929-1968)

Photo Archive @ http://www.tearnet.com/Sean
Last Updated 29 Sept. 2004

 

[Steve]

This is not my issue. My issue is the use of local time when the time
at the destination is the time that fits the problem domain.




For a hotel reservation at a hotel in New Zealand? I have never heard
of making a hotel reservation in anything but the local time of the
hotel. I am almost certain a hotel clerk in Auckland could care less
what time it is in Peru.

This is not to say using Javascript to localize displayed times in
another application is not a good idea, it just makes no sense to me
in this application.

enjoy,

Sean

Hi Sean,

Sorry about that. My newsreader has chopped off the start of the thread.
In that case, storing the timezone in the database along with the
location is the simplest way of doing it. Then you can enforce that
timezone on the server using the method I suggested earlier.

It works... honest

Steve