[d_burfoot]

My personal rule for time processing: use the language-provided libraries for ONLY 2 operations: converting back and forth between a formatted time string with a time zone, and a Unix epoch timestamp. Perform all other time processing in your own code based on those 2 operations, and whenever you start with a new language or framework, just learn those 2.

I've wasted so many dreary hours trying to figure out crappy time processing APIs and libraries. Never again!

[avalys]

Starting from timestamp A, how do I find the Unix timestamp B corresponding to exactly 6 months in the future from timestamp B?

[cryptonector]

Adding or subtracting "months" is inherently difficult because months don't have set lengths, varying from 28 through 31 days. Thus adding one month to May 31 is weird: should that be June 30 or July 1 or some other date?

Try not to have to do this sort of thing. You might have to though, and then you'll have to figure out what adding months means for your app.

[mjevans]

Welcome to Business Logic. This is where I'd really like pushback to result in things that aren't edgecases.

However you also run into day to day business issues like:

* What if it's now a Holiday and things are closed?

* What if it's some commonly busy time like winter break? (Not quite a single holiday)

* What if a disaster of somekind (even just a burst waterpipe) halts operations in an unplanned way?

Usually flexability needs to be built in. It can be fine to 'target' +3 months, but specify it as something like +3m(-0d:+2w) (so, add '3 months' ignoring the day of month, clamp dom to a valid value, allow 0 days before or 14 days after),

[TZubiri]

Do all edge cases need to be handled? Just be late when there's a holiday.

72 business hours sounds more like human time than computer time anyways.

[cryptonector]

Yes, basically, they do need to be handled, but you have to define that for your own case. It's a real pain, if you have to do month math.

[Spivak]

I think the parent is describing a "bring your own library" approach where a set of known to the author algorithms will be used for those calculations and the only thing the host language will be used for is the parse/convert.

It does remove a lot of the ambiguity of "I wonder what this stdlib's quirks are in their date calculations" but it also seems like a non-trivial amount of effort to port every time.

[d_burfoot]

The difficulty of this problem rests on the ambiguity of the phrase "exactly 6 months", which is going to depend totally on the precise business logic. But there's no reason to suppose that the requirements of the business logic will agree with the concepts implemented by the datetime library.

[layer8]

"Exactly 6 months in the future" from an arbitrary timestamp is not well-defined, even when assuming a fixed time zone. What is it supposed to mean?