[ic] time tag with adjust in February bug?

Peter 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
> more.

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 mailing list