[ic] time tag with adjust in February bug?

Paul Jordan paul at gishnetwork.com
Mon Apr 1 16:07:50 UTC 2013


> Quoting Mike Heins
> Quoting Paul Jordan (paul at gishnetwork.com):
> > > users-bounces at icdevgroup.org] On Behalf Of Mike Heins Quoting Peter
> > > (peter at pajamian.dhs.org):
> > > > On 04/02/2013 01:00 AM, Mike Heins wrote:
> > > > >The only way to do this properly would be to run mktime after
> > > > >each atom of adjustment, generating a new @times array, and then
> > > > >apply the next. Even then, you may not get what you think you are
> going to get.
> > > >
> > > > Right, even adjusting just the month you get:
> > > >
> > > > 31st Mar - 1 month = 31st Feb which gets corrected to 3rd of Mar
> > > > (or 2nd if it's a leap year).  Fail already.
> > > >
> > > > The only way I can think of to do this "correctly" is to use
DateTime.
> > > > What I could do is check for the existence of DateTime and use
> > > > that if it's present, and fall back to the existing code otherwise.
> > >
> > > Yes, that makes sense. Originally, I didn't want to deal with months
> > > as a standard function precisely because the behavior of months is
> > > truly undefined. Even the date modules Date::Calc and DateTime,
> > > either of which
> >
> >
> > But a month is well defined and (to Peter), it is an exact science.
> 
> I don't agree with this.
> 
> > Months is any number of months, not any number of days. It is a
> > calendar term, and not a representation of a calculable amount of days
> > except in the most casual ways. No definition ever gives it a set
> > amount of days either, but defines it as one of the twelve portions of
> > the calendar year.
> 
> You can't do month math in a consistent way.
> 
> >
> > If one wanted to subtract 40 days, they'd say subtract 40 days, not
> > subtract one month 10 days - as that clearly makes presumptions.
> 
> Presumptions that you have to define yourself.
> 
> >
> > It seems to me that when combining terms, we'd operate on the largest
> > to the smallest. Minus 1 month from the month's position (date wise,
> > not mathematically), then that date is verified, if it is *not* found
> > to be an accurate date, one day is decremented until it is found to be
valid.
> >
> > I say this because since the only conflicts happen at the end of
> > months, then when adding or subtracting months, if you come to an
> > invalid time, your original intention would always be the most valid
> > date closest to the original date - because your intention would never
> > be to add 6 months when you asked to add 5 - it would always be to
> > remain in the 5th month - no more.
> >
> > Then the other components are handled normally. The above verification
> > process is only needed after the Months processing.
> >
> > Examples:
> >   March 31 - 1 month = Last day of Feb
> >   January 30 + 1 month = Last day of Feb
> >   January 31 + 1 month = Last day of Feb
> >
> > The reason this is like this is because we are dealing with the term
> > of a Month, and not an amount of days.
> >
> > Minus a month does not mean:
> >    - let's decrement the amount of days in this month
> >    - Let's decrement 31, 30, 29, or 28 days
> >
> > I cannot comment on DST, but it seems to me the only issue is with
> > Months, as that is the only position that would be mathematically
variable.
> 
> There is no month math. If there was, you could add a month to Jan 31 and
> get Feb 31. Not possible. So you have to build your own set of rules that
you
> define if you want to have a treatment of that.


Math works with variables all the time.  A Month (a variable) has a
world-wide usage of:

A) On January 15th, I ask you to meet me here one month from today, you
don't add 28, 29, 30, or 31 days to this date, you increment the month and
meet me on February 15th.

B) On January 31st, I ask you to meet me here one month from today,
likewise, you don't add any amount of days, but rather meet them at the end
of February. To presume anyone but David from Prometheus would show up on
March 3rd, or perhaps March 2nd depending on the year, is not the way humans
use "Month".

In fact, in Prometheus, David (a computer) when asked how long they have
been travelling he says "2 years 4 month 18 days 36 hours". 36 hours? It's
because a computer knows a "day" has an actual meaning to humans, and is not
just 24 consecutive hours.

By using a "month" you are explicitly choosing to use a variable that exists
only in society, and its usage should meet a logical conclusion, not an
illogical one. If all humans use the variable "month" in the same way, then
yes - there is month math. If one desires something different, then they can
create their own function and maybe that is what Peter should have done back
in 2009, repurposed the code into a completely new human-friendly tag.

Just as we don't add 1 to 12, to be 13 for January's numerical month, we are
using a computer to work with the way humans perceive time. Because this
yearly transition be expressed easily in Math, doesn't mean it is more valid
than another one of our perceptions of time. 

The logic I have shown also prevails on February 29th, we +/- one year (or
12 months). Since the definition of a year is 365 days OR 366 days, a result
of February 28th is valid - our "fuzzy logic" simple determine if it was
more appropriate to use 365, or 366 days.

I am just saying, if we keep the "month" usage in the tag, it should work
how the vast majority of humans would expect it. 

All I needed was the last days of the previous months, which I can do with a
facility built into Mysql - the time tag was just killing two birds with one
stone.

Paul





More information about the interchange-users mailing list