4 ms·
It's actually quite useful, because for us human beings thinking in months is natural. Think about a user setting for some kind of web notification service: Ho
by zubspace 11y ago
It's actually quite useful, because for us human beings thinking in months is natural. Think about a user setting for some kind of web notification service:
How often do you want to be notified:
* Once per month
* Once each quarter of a year
* Twice a year
It's straightforward if you can add the number of months to the sign up date. You simply need to define the edge conditions. Example in C#:
The AddMonths method calculates the resulting month and year,
taking into account leap years and the number of days in a month,
then adjusts the day part of the resulting DateTime object. If the
resulting day is not a valid day in the resulting month, the last
valid day of the resulting month is used.
For example, March 31st + 1 month = April 30th.
https://msdn.microsoft.com/en-us/library/system.datetime.addmonths%28v=vs.110%29.aspx https://msdn.microsoft.com/en-us/library/system.datetime.add...
I think ruby does the same.
- jerf 11y agoIn typed languages, I'd suggest a case could be made that once you add a "month" to a time, you should get a different type out that should either support a grossly reduced set of operations, or one that would require formal unpacking to produce a "real" datetime that would once again support normal operations. Months and years are dangerous things. (Days technically aren't constant either, but there's a lot of applications like billing where a leap second won't bother you at all if your month & year code just deal with them.)
- agentultra 11y agoAdd in timezones and you have a whole barrel full of monkeys to deal with. Especially if you have two integrated systems with databases in different timezone formats. Trying to teach computers how to interpret time the way we do intuitively is a peanut butter sandwich experiment. Tedious, frustrating, error prone, and messy.