Posted by Steve on 03/22/07 14:46

"J.O. Aho" <user@example.net> wrote in message
news:56fi8aF280potU1@mid.individual.net...
| Adam wrote:
| > On Thu, 22 Mar 2007 14:47:56 +0100, J.O. Aho wrote:
| >
| > Wow! After a *long* break from this group, i'd forgotten how lightning
| > fast people here are ;-) Good to be back!
| >
| >>> I need to be able to return the corresponding dates for Mondays - and
| >>> have tried various functions, scripts with varying degrees of success.
| >>> date('d-M-Y', strtotime('this monday'));
| >>>
| >>> ... works, as does:
| >>>
| >>> date('d-M-Y', strtotime('last monday'));
| >>>
| >>> However, whilst this function works well most of the time, for some
| >>> reason it pukes on Monday 19th March - and always returns 18th Mar
| >>> (which is a Sunday!).
| >
| >> Sure you haven't set the year to 2002 or 2013?
| >
| > Nope - I'm not playing with the year in any way.
| >
| >> Does "date('d-M-Y', strtotime('last monday')+1);" make any difference?
| >
| > Yes. The only way I could kludge it was to use:
| >
| > date('d-M-Y', strtotime('last monday')+7)
| >
| > - which gave the correct date (Mon 12th + 7 = Mon 19th). It was "this
| > monday" that was returning the wrong date.
|
| You know that +7 is only 7 extra seconds and not seven days, 7 days =
604800
| seconds.
|
| It could of course be as Geoff says to do with the DST, specially now when
the
| DST has been moved at the USA and we have the problem of people who do not
| keep their systems up to date, this seems to be a problem more common on
| microsoft systems, but not only limited to those, I would suggest you add
an
| hour to the time you get with strtotime().
|
| date('d-M-Y', strtotime('last monday')+3600);
|
| http://www.php.net/manual/en/function.strtotime.php
|
| When getting a date, it don't make any difference if you take the date
that is
| at midnight or quarter to twelve next midnight, the date itself will be
the same.

i agree. i've seen others have date calc problems here along with some good
feedback as to why they happen. each solution relied on either being
specific with the time, ensuring that it was not 00:00:00, and in this case,
even adding an hour...which should circumvent this problem as well.

good on ya.

[Back to original message]