[JadeNB]

> "When doing math that deals with time, specifically different units of time, it can lead to unexpected results if you are not careful with the ordering"

Not arguing with you, but with the poster: I think that a deeper lesson might be the important realisation that, unlike 'day' or 'hour', 'month' is not a unit of time! (At least, not any more than 'moment' is. (I know, I know, https://en.wikipedia.org/wiki/Moment_(time), but you know what I mean.))

[cies]

> unlike 'day' or 'hour', 'month' is not a unit of time!

Not a 'fixed unit' of time. Where I define 'fixed' as being always of the same size (like gram or meter).

My next thought is that day is also not fixed in case of daylight saving and leap seconds. A day has many definitions: astronomical, 24 hours, calendar, etc.

Maybe we can also see this problem with 'hour'; but in that case it would be more contrived.

Bottom line: programming time is hard, be aware of that.

See this post for some common pitfalls:

http://infiniteundo.com/post/25326999628/falsehoods-programm...

[JadeNB]

> Not a 'fixed unit' of time. Where I define 'fixed' as being always of the same size (like gram or meter).

I would regard that as part of what 'unit' means (https://en.wikipedia.org/wiki/Units_of_measurement), though I'm not sure that there's any universal agreement.

I think that it's fair to say that even, or perhaps especially, the most obvious concepts, when sufficiently well understood, exhibit subtleties. (I always tell students in my mathematics classes that the correct answer to every question is "it depends", and, though it's somewhat facetious, I honestly can't think of a mathematical statement so basic and obvious that a sufficiently sophisticated mathematician couldn't correctly raise this objection.)

With that said, while I agree that there may be different colloquial definitions of 'day' and, as you mention, of 'hour', and even of 'second' (https://en.wikipedia.org/wiki/Second#Other_current_definitio...), they also have unambiguous scientific definitions that can be pinned down by sufficiently precise reference; whereas 'month' simply does not.

EDIT: I should clarify that I'm not attempting by any of this to say that programming with times isn't hard—it absolutely is. I just think that a large part of it can be traced to confusion about what is not a unit (which, as observed by cies above (https://news.ycombinator.com/item?id=9665366) and DannoHung below (https://news.ycombinator.com/item?id=9665472), can include such seemingly innocuous concepts as 'day'), and that it might be profitable explicitly to state this unifying idea as one way to guide attempts to program successfully with time.

[DannoHung]

As long as we're posting wikpedia links: http://en.wikipedia.org/wiki/Leap_second

I wouldn't trust any time unit larger than seconds if I was concerned about my units staying consistent. Hopefully time-keeping bodies don't decide we need leap-millis at some point.

Which is only to say that this is a problem that can't be solved simply by discarding some concepts that you find problematic. There's a lot of shit about timekeeping that's problematic. I'd advise tossing all the problematic shit when trying to figure out some internal representation for the underlying time that more or less always makes sense and then building out more human-usable representations with the uglyness on top of it.

[JadeNB]

> Which is only to say that this is a problem that can't be solved simply by discarding some concepts that you find problematic.

> I'd advise tossing all the problematic shit when trying to figure out some internal representation for the underlying time that more or less always makes sense and then building out more human-usable representations with the uglyness on top of it.

I don't mean to be snarky, but these two sentences seem contradictory—you say that the problem can't be solved by discarding problematic concepts, then advise to discard problematic concepts. Are you making the point that, even if internally we work with an un-problematic representation of time (if such a thing exists!), at some point we have to convert to and fro? Certainly I agree with that. Though I seem to have said it badly, that's really what I meant to say above: trying to work directly with months (and, perhaps less dramatically, with days), which are not units of time, allows the problematic real-world notion of time to contaminate what should be the clean internal representation of it.

[DannoHung]

I guess? I'm saying that you can't realistically avoid working with the problematic units. Like, if you want to have a monthly payment system, at some point, you have to bake in the human concept of months into your system, warts and all.

[LukeShu]

When my cell plan was with T-mobile, I was on a pre-paid plan. My bill was due once a month, so I set up monthly automatic billing. Well, the system that enabled or disabled my service depending on if I had paid considered that to be "every 30 days". The system that handled the automatic payments considered that to be the same day every month (IIRC, it charged my card on the 18th of every month; when I set it up my bill was due on the 20th). A couple of 31-day months later, and I lose service for a day because the automatic payments didn't keep up with the bill being due.