[ic] time tag with adjust in February bug?
mike at perusion.com
Mon Apr 1 16:13:16 UTC 2013
Quoting Paul Jordan (paul at gishnetwork.com):
> > 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
> > > > > 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
> > >
> > > 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
> > 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
> > 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".
That is your definition. It's fine, but you are basing it on assumptions
which are not universal.
> 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.
I am not in favor of keeping it, because "vast majority" is not precise
enough for computer language.
> 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.
That's why you write your own code for it. It does what you expect it
to do, and if you operate under someone else's assumptions you may
not get that.
Perusion -- Expert Interchange Consulting http://www.perusion.com/
phone +1.765.253.4194 <mike at perusion.com>
One conclusion should be obvious: If nations such as Indonesia,
Bangladesh and Thailand can not make themselves inoffensive to Militant
Islamism there is no way that the United States could perform such a
feat, no matter which policies we changed or how much our public
diplomacy improved. -- Clifford May
More information about the interchange-users