3 ms·

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

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 2y ago
Starting from timestamp A, how do I find the Unix timestamp B corresponding to exactly 6 months in the future from timestamp B?
- Spivak 2y ago
  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.
- cryptonector 2y ago
  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 2y ago
    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 2y ago
      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 2y ago
        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.
- d_burfoot 2y ago
  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 2y ago
  "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?

avalys 2y ago

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

Spivak 2y ago
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.
cryptonector 2y ago
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 2y ago
  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 2y ago
    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 2y ago
      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.
d_burfoot 2y ago
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 2y ago
"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?