Soon after I sent my email, I realised that it was wrong - oops :(

As Steve Cayford said, use timestamps and then convert it back into whatever
format you want

I think the best way to work with dates is not to :) find someone else's
code that works and use that - dates are awful!!

  $today = mktime(0, 0, 0, date("m"), date("d"), date("Y"));
  $last_week = mktime(0, 0, 0, date("m"), date("d")-7, date("Y"));
  $diff = $today - $last_week;
  echo $diff / 86400; // (60 sec/min * 60 min/hr * 24 hr/day)

Your comment about not using dd/mm/yy or mm/dd/yy I totally agree with - I
use dd-Mon-YYYY format for my dates for that reason...


-----Original Message-----
From: DL Neil [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, January 08, 2002 10:42 AM
To: Boget, Chris; 'Sander Peters'; [EMAIL PROTECTED]; Martin
Subject: Re: [PHP] counting with dates (help!)

RE: [PHP] counting with dates (help!)Hi Sander,
(and Chris, and Martin)

> $today = date("Ymd", mktime(0,0,0, date(m),date(d),date(Y)));
> $last_week = date("Ymd", mktime(0,0,0, date(m),date(d)-7,date(Y)));
> echo ($today - $last_week);
> The result is a number like 8876 (20020107-20011231 = 8876)
> But in date thinking it should be 7!
No, that's the difference in time represented by the number of seconds.
You still need to work with it a little more.
8876 / 60 = number of hours  /* 60 = number of seconds in an hour */
8876 / 60 / 24 = number of days.  /* 24 = number of hours in a day */

=I'm sorry but neither the above, nor the suggestion of Julian dates was
correct (in all cases). The two numbers
($today and $last_week) generated in the PHP code above are in CCYYMMDD
format (as used by MySQL to store dates,

=So you are correct (Sander):
20020107 less
20011231 equals

=but this number is meaningless. If the formulae proposed above are applied,
the answer is not 7 days.

=Similarly (Julian dates = CCYYDDD format)
2002007 less
2001365 equals

=However let's jump forward in time, to tomorrow (hey what's 45 minutes
between friends?):
20020108 less
20020101 equals

2002008 less
2002001 equals

=woohoo! How come they 'work' tomorrow but not today? Because (using the
first format) whilst the last and
second to last digits represent days (hence it 'works' tomorrow), the
preceding pair of digits represent months,
and the procession of days into months is not a decimal progression. (smack
your forehead into the wall
now...but don't do it too often, because no matter how good it feels, it'll
feel a whole lot better when you

=this is also the reason that using a Julian date format won't work - they
look like decimal numbers (look like
a duck), you can perform arithmetic on them (walk like a duck), but if your
calculation spans a year-break you
will discover that they are not really decimal numbers (and they bark like a

=The three main date formats are:

1 CCYYMMDD (as mentioned above) because it is the way MySQL does things. You
can't use this for 'real
arithmetic' as we've just discussed, but you can do comparisons,
eg is 'today' > 'yesterday' (when I was young...)

2 dd-mmmmmm-ccyy (or variant) which is the way humans like to read their
dates. This is for appearances, and
once again not for arithmetic/logic.
PS never, never, never (did I say "never") use dd/mm/yy or mm/dd/yy because
of the ambiguities it causes -
particularly between Americans and the rest of the world (and date-guessing
functions - see your manual)

3 UNIX Epoch timestamp which is a count of the number of seconds since
midnight 1 Jan 1970 (GMT). This is an
absolutely ugly way to look at dates (and times), but it is really easy to
use for arithmetic and after a while
you don't think it at all odd that without any effort you can recall that
there are 86,400 seconds in one day.

=Now that piece of trivia, a pocket protector, and band-aid keeping your
spectacle frames together will make you
a babe-magnet in every bar (well those that serve Heineken anyway).

=Putting aside several HOURS to study the two manuals to get your head
around date functions is time well spent
(yes I know, it takes me a little longer...) - particularly the sheer number
of SQL date functions (the power of
which is all too frequently overlooked). Regarding the PHP functions, I made
a page list, and as I made notes
about each one, I annotated it with a 'purpose' so that I could keep them
straight in my mind. Well, enough of
me and there reasons why girls in bars don't talk to me...

=Let me do my usual frustrating thing and ask you what you are REALLY
wanting to do. You don't actually want to
subtract those two numbers/PHP variables, because you already know the
answer in their very creation...


Reply via email to