• C-Derb (unregistered) in reply to chubertdev
    chubertdev:
    Should be ">="

    Also, what happens when the DOB is stored with time? I was born at 11:46pm, but I was able to drink before that time on my 21st birthday.

    This is just proof of concept code. Do you want your money back? Obviously you would also have to check the Person.IsPedanticAsshole property to determine if there's a need to check the timestamp. Duh. Everybody knows that.

  • CAPTCHA: VERTO (unregistered) in reply to chubertdev
    chubertdev:
    C-Derb:
    caffiend:
    C-Derb:
    It actually ain't that hard, since most societies with age related drinking laws are measured in years, not days, of age. For example, in the United States*, legal drinking age is 21 years old, not 7,665 days old.

    Yes... that's my point.

    You'd expect to be able to write

    if ((DateTime.Now - person.DOB).Years > 21) DirnkMachine.Despence();

    But there is no "Years" method. I'm not saying it's hard to implement, it's not, I'm just surprised it's not part of the standard libraries of the most commonly used languages in use.

    This C# doesn't work for you?
    if(person.DOB.AddYears(21) < DateTime.Now)
    {
      DrinkMachine.Despence();
    }
    

    Should be ">="

    Let's assume somebody was born on the 1st of January 1970 (the dawn of time, after all) and now is the 1st of January 1980. According to you (1991 >= 1980 returns true) they can go order a large whiskey and a double vodka. But they can't for their 22nd birthday in 1992 (1991 >= 1992 returns false).

  • VB (unregistered) in reply to Greg

    An incompetent java programmer.

  • anonymous coward (unregistered) in reply to caffiend
    caffiend:
    chubertdev:

    Unless you want to write a loop and implement the logic you're self, you're out of luck.

    What i was referring to is the absence of methods like.

    TimeSpan.Years or TimeSpan.Months

    which is what you get from the arithmetic operators on DateTime objects in C#, I'm pretty sure Java is similar. Oh, no wait, in Java you get to chose whether you want to get you're results using the Gregorian calender or the Julian calender (because the flawed date-keeping system used in ancient Rome might be useful to me).

    I'm sorry, I shouldn't rant, the only thing worse than computational representations of date & time is how to handle daylight savings.

    uh, what are you talking about?

    bool canDrink = DateTime.Parse(AnyCommonStringRepresentationOfABirthDay).AddYears(18) <= DateTime.UtcNow;

  • Scboffspring (unregistered) in reply to anonymous coward

    Lol.

    canDrink = DateTime.Parse("12.02.1990").AddYears(18) <= 17.09.2014 = false

    So now that I'm 23, I can't drink anymore. TRWTF.

  • Scboffspring (unregistered) in reply to Scboffspring

    Oh actually I may be drunk. Cannot even do simple boolean logic.

  • nmclean (unregistered) in reply to caffiend
    caffiend:
    C-Derb:
    This C# doesn't work for you?
    if(person.DOB.AddYears(21) < DateTime.Now)
    {
      DrinkMachine.Despence();
    }
    

    Actually it does, I'm man enough to admit when I'm wrong. You've just helped me delete 30 or so lines of code, and despite the embarrassment on here, I'm happy with that. Didn't know that was there.

    Thanks :)

    Also, there is a very good reason why the method you expected to be available isn't: a TimeSpan value is independent from start and end dates. It is exactly what it's called -- a span of time -- and no more. If it had a notion of months and years, what is it supposed to do when you add it to another date? e.g. What is TimeSpan.Months for 30 days: 0 or 1? If you add it to Jan 31, should the result be Feb 28, or March 2? Same issue applies to leap years.

  • Lame (unregistered) in reply to Smug Unix User
    Dates are hard for most programmers to get.
    No need to bring our personal lives into it.
  • ph (unregistered) in reply to caffiend
    If anyone is still writing new business logic in C++ these days they deserve what they get.

    People use C++ because there is no better alternative. It is the single widely used language where you can build up any number of abstraction layers to match the application domain, with zero or minimal performance penalties. Of course, having such a sharp knife makes it possible to cut off your feet, but C++ provides enough means to adapt or build your own ecosystem which is exactly as safe as you want.

    I would gladly welcome a comparable language without all those C++ gotchas, but I'm afraid this might impact the sharpness.

  • Bill C. (unregistered) in reply to Zylon
    Zylon:
    Dates are hard, full stop. 99% of humans don't have to deal with dates in their full unholy madness. Programmers do.
    Only the inner component of the date is hard. It's surrounded by a soft outer component. The rest can be explained by a fruit vendor and a cunning linguist.
  • (cs) in reply to C-Derb
    C-Derb:
    chubertdev:
    Should be ">="

    Also, what happens when the DOB is stored with time? I was born at 11:46pm, but I was able to drink before that time on my 21st birthday.

    This is just proof of concept code. Do you want your money back? Obviously you would also have to check the Person.IsPedanticAsshole property to determine if there's a need to check the timestamp. Duh. Everybody knows that.

    Are you claiming that someone on TDWTF is too pedantic? Hah, that's funny.

  • (cs) in reply to CAPTCHA: VERTO
    CAPTCHA: VERTO:
    Let's assume somebody was born on the 1st of January 1970 (the dawn of time, after all) and now is the 1st of January 1980. According to you (1991 >= 1980 returns true) they can go order a large whiskey and a double vodka. But they can't for their 22nd birthday in 1992 (1991 >= 1992 returns false).

    Let's assume that I didn't make a tpyo.

  • Aatch (unregistered) in reply to ph

    Rust is aiming to be that language. I doubt it's exactly what you want currently, as the language is still being finalised. (End of 2015 is the estimated 1.0 release), but the goal is essentially to be a replacement for C++.

    It's plenty sharp too. It's easy to write safe code in Rust that runs as fast as equivalent C/C++. If you can't convince Rust something is safe, you can drop down into "unsafe" mode (which really only adds the ability to deference raw pointers).

    It's not gotcha-free (no language is), but the gotchas tend to result in compile-time errors rather than segfaults or memory leaks.

  • Dirk (unregistered)

    This was a good one!

  • eric76 (unregistered)

    Can someone get the author of that code to write a routine to determine whether or not a number is a prime number and post it here?

  • ROFL (unregistered) in reply to nmclean
    nmclean:
    Also, there is a very good reason why the method you expected to be available isn't: a TimeSpan value is independent from start and end dates. It is exactly what it's called -- a span of time -- and no more. If it had a notion of months and years, what is it supposed to do when you add it to another date? e.g. What is TimeSpan.Months for 30 days: 0 or 1? If you add it to Jan 31, should the result be Feb 28, or March 2? Same issue applies to leap years.

    Which is the reason you never sell or buy MM contracts on Feb 29 unless you have no choice. But there is always an answer. For listed instruments the calculation will be in the standard contract used by the exchange where the instrument is listed.

    Any real finance/treasury library explicitly deals with those questions. There are 3 answers that capture 90% of the contracts, and another 6 that probably capture the next 9%.

  • Junior (unregistered) in reply to Aatch
    Aatch:
    It's easy to write safe code ... that runs as fast as equivalent C/C++.

    Where is this idea that C/C++ is fast coming from? Are you comparing it to Lisp? JavaScript?

    The enourmous work that has been done on making optimising compilers for C/C++ is because C and C++ are languages that make it very difficult to compile fast code. Almost any other native-compiled language is going to be at least as fast as C/C++ It's not a high bar to leap.

  • QJo (unregistered) in reply to caffiend
    caffiend:
    Yeah, whoever wrote this was a brain-dead moron, but even modern languages don't seem to have built-in functions to deal with leap years properly.

    The algorithms involved aren't particularly complex, but both Java and .NET are both lacking in utility functions which accurately handle them... (the scripting oriented languages like python, ruby or dare i say it perl may be better at this, but i haven't tried, maybe Ben could even give us a solution in Go!)

    For example, try writing a function to tell from a date of birth of someone is over the legal drinking age in either Java or C#. It sounds easy, but the utility function you'll probably reach for is strangely absent.

    I'm not sure what the legal drinking age is in Java. In the UK it's 18, and in (at least most of) the US it's notoriously 21 (which is of course TRWTF). I don't know where in the world C# is, so haven't a clue what the legal drinking age there is.

  • QJo (unregistered) in reply to caffiend
    caffiend:
    Someone else:

    I'd just as soon reach for NodaTime/JodaTime.

    And then spend the same amount of time trying to get any ORM to store those objects in a database without completely screwing up you're domain model.

    At least your consistent, but please learn you're grammar.

  • QJo (unregistered) in reply to C-Derb
    C-Derb:
    caffiend:
    C-Derb:
    It actually ain't that hard, since most societies with age related drinking laws are measured in years, not days, of age. For example, in the United States*, legal drinking age is 21 years old, not 7,665 days old.

    Yes... that's my point.

    You'd expect to be able to write

    if ((DateTime.Now - person.DOB).Years > 21) DirnkMachine.Despence();

    But there is no "Years" method. I'm not saying it's hard to implement, it's not, I'm just surprised it's not part of the standard libraries of the most commonly used languages in use.

    This C# doesn't work for you?
    if(person.DOB.AddYears(21) < DateTime.Now)
    {
      DrinkMachine.Despence();
    }
    
    if(person.DOB.AddYears(21) < DateTime.Now)
    {
      DrinkMachine.Dispense();
    }
    

    FTFY

    Quite a few of the contributors are displaying more or less illiteracy in their responses to this post. I despair of the education system of the nation to which they have the misfortune to belong.

  • QJo (unregistered) in reply to eric76
    eric76:
    Can someone get the author of that code to write a routine to determine whether or not a number is a prime number and post it here?

    Let me guess -- here's the pseudocode:

    if (number == 2) return true;
    
    if (isOdd (number)) {
        return true;
    } else {
        return false;
    }
    

    Reasoning: everybody knows 2 is a prime, it's famous for being the only even prime, even I know that.

    So let's look at the odd numbers. 3 is prime. 5 is prime. 7 is prime. 9 is prime. 11 is prime. 13 is prime. We can extrapolate from there.

    Sorry, what was that, nine isn't prime? Okay, no worries, I've made a fix to isOdd so as to make sure it returns 9 as false.

    Sorry, you said "what about 1"? Oh good grief, stop making so much fuss over edge cases!

  • John S (unregistered) in reply to Kristof Provost
    Kristof Provost:
    Pet peeve. It almost certainly won't do that. Modern operating systems overallocate memory. They hand out virtual memory space to processes without backing them with real memory (there's a metaphore for the modern banking system in there somewhere). The physical memory isn't allocated unil you actually write to the virtual memory.

    In other words: no execption. The kernel would just kill this process.

    Nope.

    What if the Date object has a constructor?

  • coldandtired (unregistered) in reply to caffiend
    caffiend:
    The algorithms involved aren't particularly complex, but both Java and .NET are both lacking in utility functions which accurately handle them...
    C# DateTime.IsLeapYear(2014);
  • Jeff Dege (unregistered)

    In my mind, the real question is why was a single process allowed to allocate so much memory as to bring the machine as a whole to its knees?

    Isn't it the sysadmin's responsibility to configure system limits so as to prevent this sort of thing?

    I can see leaving (ulimit|Windows System Resource Manager|whatever), configured to its defaults on a dev or QA machine, but not on a business critical production server.

    One badly-behaved program should not be able to bring down the server. And there will always be badly-behaved programs.

  • Dan (unregistered) in reply to Zylon
    Zylon:
    Smug Unix User:
    Dates are hard for most programmers to get.
    Dates are hard, full stop. 99% of humans don't have to deal with dates in their full unholy madness. Programmers do.

    .....rowwraaawwwraowwwaooowwwdugudugudugaWHOOOOOOOOOOOOOSH!!!

  • dolor (unregistered) in reply to Junior
    Junior:
    Where is this idea that C/C++ is fast coming from? Are you comparing it to Lisp? [...] Almost any other native-compiled language is going to be at least as fast as C/C++
    Your post contradicts itself.
  • (cs) in reply to ph
    ph:
    If anyone is still writing new business logic in C++ these days they deserve what they get.

    People use C++ because there is no better alternative. It is the single widely used language where you can build up any number of abstraction layers to match the application domain, with zero or minimal performance penalties. Of course, having such a sharp knife makes it possible to cut off your feet, but C++ provides enough means to adapt or build your own ecosystem which is exactly as safe as you want.

    I would gladly welcome a comparable language without all those C++ gotchas, but I'm afraid this might impact the sharpness.

    Have you heard of SCALA or are you living under rock?

  • Instigator (unregistered) in reply to caffiend
    caffiend:
    Yeah, whoever wrote this was a brain-dead moron, but even modern languages don't seem to have built-in functions to deal with leap years properly.

    The algorithms involved aren't particularly complex, but both Java and .NET are both lacking in utility functions which accurately handle them... (the scripting oriented languages like python, ruby or dare i say it perl may be better at this, but i haven't tried, maybe Ben could even give us a solution in Go!)

    For example, try writing a function to tell from a date of birth of someone is over the legal drinking age in either Java or C#. It sounds easy, but the utility function you'll probably reach for is strangely absent.

    .net definitely has it's shortcomings, but this is not one of them.

     public bool IsOver21(DateTime dob)
     {
       return DateTime.Today >= dob.AddYears(21);
     }
    
  • AC (unregistered) in reply to QJo

    Scotland is 5. Yes 5

    http://www.adviceguide.org.uk/scotland/relationships_s/faq_index_family_scotland/faq_family_legal_age_drinking_and_smoking_scotland.htm

  • I Appreciate Wit (unregistered) in reply to Smug Unix User

    Not true! I've gotten plenty of dates... Before I was a programmer.

  • nmclean (unregistered) in reply to dolor
    dolor:
    Junior:
    Where is this idea that C/C++ is fast coming from? Are you comparing it to Lisp? [...] Almost any other native-compiled language is going to be at least as fast as C/C++
    Your post contradicts itself.
    No. He is saying these two things:
    1. C/C++ are fast compared to Lisp and JavaScript.
    2. C/C++ are slow compared to other native-compiled languages.

    Lisp and JavaScript are not native-compiled languages; this is not a contradiction.

  • nmclean (unregistered) in reply to ROFL
    ROFL:
    nmclean:
    Also, there is a very good reason why the method you expected to be available isn't: a TimeSpan value is independent from start and end dates. It is exactly what it's called -- a span of time -- and no more. If it had a notion of months and years, what is it supposed to do when you add it to another date? e.g. What is TimeSpan.Months for 30 days: 0 or 1? If you add it to Jan 31, should the result be Feb 28, or March 2? Same issue applies to leap years.

    Which is the reason you never sell or buy MM contracts on Feb 29 unless you have no choice. But there is always an answer. For listed instruments the calculation will be in the standard contract used by the exchange where the instrument is listed.

    Any real finance/treasury library explicitly deals with those questions. There are 3 answers that capture 90% of the contracts, and another 6 that probably capture the next 9%.

    I don't know what you're talking about, but I don't see why it needs to be this complicated. There is only a problem when the unit of time you want to work with is ambiguous. If we know that we want to work in months or years, we shouldn't be putting 30 or 365 days into the system in the first place; we should be adjusting the month or year component directly (and temporarily rolling back the day-of-month as needed when it is out of bounds). How are there 9 different answers to this?
  • Jeff Dege (unregistered) in reply to nmclean

    What people don't grasp is that the elapsed time between any two events is indeterminate. Given any two date/times, you cannot determine how much time elapsed between them without a database, for past times, and and not at all, for future times.

    Prior to 1970, there were a fixed number of seconds in a year, so the calculations were simple, but the length of a second was variable. Since 1970, we've fixed the length of the second, but we change the number of seconds in a year, at regular intervals.

    We base our calendars and clocks on the rotation of the Earth, but the simple fact is that the rotation of the Earth isn't constant, and its variation is not predictable.

    So no, it's not simple. Or, rather, it's only simple if you ignore what is really going on.

  • not an anon (unregistered) in reply to Jeff Dege
    Jeff Dege:
    What people don't grasp is that the elapsed time between any two events is indeterminate. Given any two date/times, you cannot determine how much time elapsed between them without a database, for past times, and and not at all, for future times.

    Prior to 1970, there were a fixed number of seconds in a year, so the calculations were simple, but the length of a second was variable. Since 1970, we've fixed the length of the second, but we change the number of seconds in a year, at regular intervals.

    We base our calendars and clocks on the rotation of the Earth, but the simple fact is that the rotation of the Earth isn't constant, and its variation is not predictable.

    So no, it's not simple. Or, rather, it's only simple if you ignore what is really going on.

    You, sir, deserve a medal for this. (I wonder if that also explains why the Unix epoch was chosen to be Jan 1, 1970...)

  • Mike (unregistered)

    Also note that the author thinks all leap years have last digit of 0, 4, or 8. But 2012 and 2016 are leap years.

  • Was the truth table wooden? (unregistered) in reply to Jeff Dege
    Jeff Dege:
    Given any two date/times, you cannot determine how much time elapsed between them without a database, for past times, and and not at all, for future times.
    True.
    Jeff Dege:
    Prior to 1970, there were a fixed number of seconds in a year, so the calculations were simple, but the length of a second was variable. Since 1970, we've fixed the length of the second, but we change the number of seconds in a year, at regular intervals.
    False. If we changed the number of seconds in a year at regular intervals, you wouldn't need a database.
    Jeff Dege:
    We base our calendars and clocks on the rotation of the Earth, but the simple fact is that the rotation of the Earth isn't constant, and its variation is not predictable.
    True.
    Jeff Dege:
    So no, it's not simple. Or, rather, it's only simple if you ignore what is really going on.
    False. Even if you ignore what is really going on, what is really going on still isn't simple.
  • Robert (unregistered) in reply to Aatch
    Aatch:
    Rust is aiming to be that language. .... It's not gotcha-free (no language is), ....

    I just checked and Rust does have a certain gotcha I hate: it uses C-style month numbering (0 to 11) rather than human month numbering (1 to 12).

    If I complain about this, I wonder if they will fix it. C-style month numbering might -- might -- have made sense forty years ago, but by no means does it make sense today.

  • aptent (unregistered) in reply to nmclean
    nmclean:
    Lisp and JavaScript are not native-compiled languages; this is not a contradiction.
    WHOOSH! Lisp most certainly is a native-compiled language, and for that matter so is JavaScript these days if you count JITting.
  • (cs) in reply to nmclean
    nmclean:
    I don't know what you're talking about, but I don't see why it needs to be this complicated. There is only a problem when the unit of time you want to work with is ambiguous. If we know that we want to work in months or years, we shouldn't be putting 30 or 365 days into the system in the first place; we should be adjusting the month or year component directly (and temporarily rolling back the day-of-month as needed when it is out of bounds). How are there 9 different answers to this?

    It was a bad example. Here are some better ones.

    One month after April 15 is May 15. Easy, eh?

    What is one month after April 30? Is it May 30 or May 31?

    One month after March 31 is April 30. One month after April 30 is possibly May 30 or May 31.

    Two months after March 31 is definitely May 31.

    February 27 to March 27 is one month.

    February 27 to March 28 is one month and one day.

    February 28 to March 28 is less than a month.

    I had to deal with end-of-month calendar issues in a client billing system I wrote and maintain.

    Sincerely,

    Gene Wirchenko

  • Robert (unregistered) in reply to Gene Wirchenko

    Months are pretty much pointless these days.

    People tend to make appointments for "next Thursday" (which has its own problems), not for such-and-such a day of such-and-such a month.

    Signs for annual events tend to be used year after year, but with the day of the month repainted annually. The day of the week does not change, and the new date is chosen to stay close to the anniversary of the old date.

    If they get rid of months and just counted weeks instead, that would be fine by me. By the way, that's exactly what they did in Iceland in the Middle Ages.

  • Norman Diamond (unregistered) in reply to Robert
    Robert:
    I just checked and Rust does have a certain gotcha I hate: it uses C-style month numbering (0 to 11) rather than human month numbering (1 to 12).

    If I complain about this, I wonder if they will fix it. C-style month numbering might -- might -- have made sense forty years ago, but by no means does it make sense today.

    No, that old rusty month numbering never made sense. If it ever were sensible, they'd have done the same things to the days of the month.

    For that matter they'd have done the same thing to the year so Unix programmers would get an extra year to fix Y2K bugs.

  • Norman Diamond (unregistered) in reply to Robert
    Robert:
    Months are pretty much pointless these days.

    People tend to make appointments for "next Thursday" (which has its own problems), not for such-and-such a day of such-and-such a month.

    Only in some languages. In Japanese you might say "next week's Thursday" so if today is Tuesday that will be 9 days later and if today is Friday that will be 6 days later, i.e. it's always the same day. In English you say "next Thursday" so you're right about having its own problems.

    However, months aren't pointless when people tend to make appointments for "next month's 12th day" or predict something for "November's first third." Weeks in the old calendar were 10 days long, which isn't exactly one-third of a month, but it's still common to talk about the upper week (first third of a month), middle week (second third of a month), or lower week (third third of a month). Not much different from talking about a quarter or a half of a year.

  • Robert (unregistered) in reply to Norman Diamond
    Norman Diamond:
    Robert:
    Months are pretty much pointless these days.

    People tend to make appointments for "next Thursday" (which has its own problems), not for such-and-such a day of such-and-such a month.

    However, months aren't pointless when people tend to make appointments for "next month's 12th day" or predict something for "November's first third." Weeks in the old calendar were 10 days long, which isn't exactly one-third of a month, but it's still common to talk about the upper week (first third of a month), middle week (second third of a month), or lower week (third third of a month). Not much different from talking about a quarter or a half of a year.

    Like I said, you could get rid of months, and people would just count weeks. A man who goes to his barber today (Monday of week 39) might make an appointment for "Monday of week 47".

  • erinnye (unregistered) in reply to Robert
    Robert:
    Norman Diamond:
    Robert:
    Months are pretty much pointless these days.

    People tend to make appointments for "next Thursday" (which has its own problems), not for such-and-such a day of such-and-such a month.

    However, months aren't pointless when people tend to make appointments for "next month's 12th day" or predict something for "November's first third." Weeks in the old calendar were 10 days long, which isn't exactly one-third of a month, but it's still common to talk about the upper week (first third of a month), middle week (second third of a month), or lower week (third third of a month). Not much different from talking about a quarter or a half of a year.

    Like I said, you could get rid of months, and people would just count weeks. A man who goes to his barber today (Monday of week 39) might make an appointment for "Monday of week 47".

    Like many companies already do. I rarely hear "we expect delivery by October 24th" but "delivery has to be in week 43" or "our salesperson will contact you tuesday week 40". All our projectios of what we expect to sell/buy/... are done by week, not month.

    But good luck for the layperson to change. Just look at how long england took to change from imperial to decimal measurement (and the public outcry when the pound was made decimal)

  • Neil (unregistered)

    Do we know that AddYears(21) won't stumble over a DST transition and therefore result in a date that's an hour off?

  • nmclean (unregistered) in reply to Iwamori
    Iwamori:
    What is the point of adding code that will bypass the 29.02 date and obviously not testing it, to be sure that software will not blow up the universe when such date occurs, instead of simple testing what happens on 29.02?
    For the preservation of the universe, of course.
  • nmclean (unregistered) in reply to Neil
    Neil:
    Do we know that AddYears(21) won't stumble over a DST transition and therefore result in a date that's an hour off?
    No. Basically, it just adjusts the Year component of the date and makes no other assumptions: 1980/X/X + 21y = 2001/X/X. If X/X is Feb 29, and the resulting year is not a leap year, it just adjusts it to Feb 28 (this means that AddYears(3).AddYears(1) doesn't necessarily give the same result as AddYears(4)).
  • nmclean (unregistered) in reply to aptent
    aptent:
    nmclean:
    Lisp and JavaScript are not native-compiled languages; this is not a contradiction.
    WHOOSH! Lisp most certainly is a native-compiled language, and for that matter so is JavaScript these days if you count JITting.
    A language is inherently neither. Obviously you can compile any language that was originally interpreted, or interpret any language that was originally compiled, if you want to. You're missing the point, which was that @Junior's post was not contradicting itself. Obviously @Junior was talking about the cases where they are not compiled, which was originally true of both Lisp and JavaScript.
  • nmclean (unregistered) in reply to Gene Wirchenko
    Gene Wirchenko:
    nmclean:
    I don't know what you're talking about, but I don't see why it needs to be this complicated. There is only a problem when the unit of time you want to work with is ambiguous. If we know that we want to work in months or years, we shouldn't be putting 30 or 365 days into the system in the first place; we should be adjusting the month or year component directly (and temporarily rolling back the day-of-month as needed when it is out of bounds). How are there 9 different answers to this?

    It was a bad example. Here are some better ones.

    One month after April 15 is May 15. Easy, eh?

    What is one month after April 30? Is it May 30 or May 31?

    One month after March 31 is April 30. One month after April 30 is possibly May 30 or May 31.

    Two months after March 31 is definitely May 31.

    February 27 to March 27 is one month.

    February 27 to March 28 is one month and one day.

    February 28 to March 28 is less than a month.

    I had to deal with end-of-month calendar issues in a client billing system I wrote and maintain.

    Sincerely,

    Gene Wirchenko

    This sounds more like a case of the client failing to describe what they want than the complexities of date processing. "Last day of the month" is not a difficult problem. If there is a choice, it should be explicitly expressed to the user:

    Bill me on: [X] End of month [ ] __ of every month

    I still don't see 9 possible variations on this...

  • anonymous (unregistered) in reply to nmclean
    nmclean:
    Gene Wirchenko:
    nmclean:
    I don't know what you're talking about, but I don't see why it needs to be this complicated. There is only a problem when the unit of time you want to work with is ambiguous. If we know that we want to work in months or years, we shouldn't be putting 30 or 365 days into the system in the first place; we should be adjusting the month or year component directly (and temporarily rolling back the day-of-month as needed when it is out of bounds). How are there 9 different answers to this?

    It was a bad example. Here are some better ones.

    One month after April 15 is May 15. Easy, eh?

    What is one month after April 30? Is it May 30 or May 31?

    One month after March 31 is April 30. One month after April 30 is possibly May 30 or May 31.

    Two months after March 31 is definitely May 31.

    February 27 to March 27 is one month.

    February 27 to March 28 is one month and one day.

    February 28 to March 28 is less than a month.

    I had to deal with end-of-month calendar issues in a client billing system I wrote and maintain.

    Sincerely,

    Gene Wirchenko

    This sounds more like a case of the client failing to describe what they want than the complexities of date processing. "Last day of the month" is not a difficult problem. If there is a choice, it should be explicitly expressed to the user:

    Bill me on: [X] End of month [ ] __ of every month

    I still don't see 9 possible variations on this...

    [ ] End of month [X] 30th of every month

    ...unless it's February?

Leave a comment on “Failure to Leap”

Log In or post as a guest

Replying to comment #:

« Return to Article