[ic] time tag with adjust in February bug?
peter at pajamian.dhs.org
Mon Apr 1 22:25:45 UTC 2013
On 04/02/2013 02:58 AM, Paul Jordan wrote:
> But a month is well defined and (to Peter), it is an exact science.
Yes, but date math when it comes to months is not. What I had done with
my code is to simply add or subtract to the month number and let
mktime() normalize the date for me. Subtracting one month and then
normalizing the date is not an unreasonable way to handle this sort of
calculation but it can (as we have found) yield results that are not
what you would probably want when you subtract one month from March 31st.
> No definition ever gives it a set amount of days either,
And this is precisely what makes it so difficult to work with.
> 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.
This does seem to me to be a more reasonable way to deal with the
> your intention ... would always be to remain in the 5th month - no
No, that's your intention, someone else's intention may be different.
> Then the other components are handled normally. The above verification
> process is only needed after the Months processing.
Months and years, then do the above step, that way we catch leap year
skews in the same exact step without needing additional code for it.
> 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
It could mean either of the above definitions to someone else, but then
the existing code doesn't do either of those things anyways so it's moot.
> 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.
DST is a different ball of wax, but there is already code to deal with
DST. By default the new code works like the old in that it simply works
(internally) on GMT and doesn't make any adjustments for DST. This
means that if you adjust past a DST boundary for your local tz then the
resulting (displayed) time will be skewed by an hour as a result. In
this mode, if you were to add 6 months to 15th Jan 2pm, you will end up
with 15th July 3pm in localtime.
There is an attribute that you can pass (compensate_dst=1) that will
tell the code to adjust the resulting time to compensate for the one
hour gain or loss due to DST so you will get a result that may be more
to your liking. In this mode if you were to add 6 months to 1th Jan 2pm
you would end up with 15th July 2pm in localtime.
Of course this attribute would end up having the opposite effect if you
display in GMT, or no effect at all if your local timezone is one that
does not recognize daylight savings (including GMT itself).
More information about the interchange-users