How to substract n days to a calendar



  •  I'm currently working on a real time automate in banking sector. This automate MUST be really fast in order to compute the right prices at the right time.

    A coworker recently showed me a function that return a
    Date representing the day of the last time the price was updated in function of a number of days.

    public Date getLastUpdateDate(int days) {
      Calendar c = Calendar.getInstance();
      c.set(Calendar.MILLISECOND, 0);
      c.set(Calendar.MINUTE, 0);
      c.set(Calendar.HOUR, 0);
                
      for (int i = 0; i < days; i++) {
         c.add(Calendar.DAY_OF_YEAR, -1);
      }
      return c.getTime();
    }

    Fortunately days can only take 1 or 7 as values (some prices are update every week others every day). There the loop won't last too long.

    Fortunately again, this code is only used in the automate initilization, not in the real time computation :)...



  • Not the most efficient implementation possible, but considering that it's only used in initialisation, I don't see the problem. Probably the first thing the developer thought of, and we all know what premature optimisation does...

    One of the coding policys at my current job is that you do not modify known working code unless there's a functional or performance related problem with it. 



  • @Mole said:

    Probably the first thing the developer thought of, and we all know what premature optimisation does...
    Pointing the obvious here, but the fact the programmer didn't think of <font face="courier new,courier">c.add(Calendar.DAY_OF_YEAR, -days);</font> instead of a for loop is the WTF.



  •  Only a minor one though really. Sometimes you don't think of things like that straight away, and hey, the code written works.The programmer may have thought of it afterwards, but why modify code that works?



  • @Mole said:

    Not the most efficient implementation possible, but considering that it's only used in initialisation, I don't see the problem. Probably the first thing the developer thought of, and we all know what premature optimisation does...

    One of the coding policys at my current job is that you do not modify known working code unless there's a functional or performance related problem with it. 

    There is a functional problem with the posted code (it's shite) and a performance problem (it's slower than Zecc's solution).

    Leaving bad code alone is merely an incentive for people to write more bad code. Don't leave it to fester - fix it and write an appropriate comment so that anyone who diffs it can see why you made the change.



  • Yes, it's shit, but it works. There's no performance problem as it's only used in the initialisation stage as described above. 

    You might change it, but I wouldn't. Why? Because although it's shit, it still works. If I change it, I have to explain to the code review board why I made the change, and then I have to create test reports to prove that the new version works just as well. I also then become the maintainer of that piece of code, and thus, if there are problems in the future (which includes people not using it right, like passing invalid parameters) I have to help. So, 2 mins to change the code, ~4 hours to get the new code accepted. Far easier to just leave code that works, working. 



  • There is exactly one "s" in "subtract."



  • @Aaron said:

    There is exactly one "s" in "subtract."

    Yes, but there are two in "substract", which is what is in the title.  The OP spelled "substract" correctly.



  •  Hate to tell you, but it's important -- the code is broken if today's date and the target date enclose a day where there is a change in daylight savings time.

     

    For example, in the USA, daylight savings time starts (for most of us anyway) on March 14th.  If today's date is March 17th, and you're going back a week, then there is a DST change in that range. Still the code is not broken, UNLESS you run it at around midnight (whether just before or just after depends on the direction of the change) you could end up with an extra day added, or a day missing - in other words, the date could be 8 days before today, or 6 days before today.

     

     



  • @morbiuswilters said:

    @Aaron said:

    There is exactly one "s" in "subtract."

    Yes, but there are two in "substract", which is what is in the title.  The OP spelled "substract" correctly.

     

    But what does it mean?



  • @Aaron said:

    But what does it mean?

     

     You're asking someone who uses "automate" (a verb) as a noun. Perhaps you should consider the source? :)



  • @dogbrags said:

    For example, in the USA, daylight savings time starts (for most of us anyway) on March 14th.  If today's date is March 17th, and you're going back a week, then there is a DST change in that range. Still the code is not broken, UNLESS you run it at around midnight (whether just before or just after depends on the direction of the change) you could end up with an extra day added, or a day missing - in other words, the date could be 8 days before today, or 6 days before today.
     

    Doesn't the code manually set the minute and hour each time its used to exactly midnight, or am I reading it wrong? 

    Secondly, I thought dst occured at 2am, not midnight. 



  • @Mole said:

    @dogbrags said:

    For example, in the USA, daylight savings time starts (for most of us anyway) on March 14th.  If today's date is March 17th, and you're going back a week, then there is a DST change in that range. Still the code is not broken, UNLESS you run it at around midnight (whether just before or just after depends on the direction of the change) you could end up with an extra day added, or a day missing - in other words, the date could be 8 days before today, or 6 days before today.
     

    Doesn't the code manually set the minute and hour each time its used to exactly midnight, or am I reading it wrong? 

    Secondly, I thought dst occured at 2am, not midnight. 

     

    D'oh -- of course the change over occurs at 2 AM, so it's the window [ 1 hour before 2:AM .. 1 hour after 2AM] that is an issue.

    As far as the day manipulation goes - I think this is Java code?  So I don't KNOW that it is broken, but I'd suspect that if you add 1 day, you're really adding exactly 24 hours; and internally the object knows whether the day it represents is in daylight savings time or not.  You can certainly run an easy test:

    The question is: when you add 1 day to the object, does it mean [the current time represented in the object, just on the following day] or does it mean [the correct time 24 hours from now].  Those are two different things, if a daylilght savings time transition occurs between one day and the next.

     


     



  • @Disconnect said:

    @Aaron said:

    But what does it mean?

     

     You're asking someone who uses "automate" (a verb) as a noun. Perhaps you should consider the source? :)

    An automate is a digital friend you don't have to control.  Duh.


  • @bstorer said:

    @Disconnect said:

    @Aaron said:

    But what does it mean?

     

     You're asking someone who uses "automate" (a verb) as a noun. Perhaps you should consider the source? :)

    An automate is a digital friend you don't have to control.  Duh.
     

    Noun stacking is an art form.



  • @Disconnect said:

    @Aaron said:

    But what does it mean?

     

     You're asking someone who uses "automate" (a verb) as a noun. Perhaps you should consider the source? :)

    [citation needed]



  •  Ok, an automaton ;)

     As for not changing the code :

    For some processes of the automatons we use, the initialization process already take hours because there is a lot to load. Therefore we should optimize it (a least a little). If nobody ever do some optimization we will end up with automatons that will not be ready before the financials markets open... therefore they will be useless...




  • @dogbrags said:

    As far as the day manipulation goes - I think this is Java code?  So I don't KNOW that it is broken, but I'd suspect that if you add 1 day, you're really adding exactly 24 hours; and internally the object knows whether the day it represents is in daylight savings time or not.

    Sorry, mate, you're wrong. The Calendar object in Java was introduced specifically to handle all those problems with date manipulations occurring from irregularities in the various calendaric systems used around the world, like DST, leap days, etc. that you would run into when trying to do your own naive implementation (usually done by adding or subtracting millisecond amounts to millisecond timestamps).

    So if you use Calendar to add a "Day" to a date, you really get the result you'd expect from adding a (logical) day, and not from adding some-fixed-length-time-interval-which-just-so-happens-to-be-the-length-of-a-day-MOST-of-the-time. Or, if you add a "Month" to a date, you get the same day of the next month (e.g. going from the 5th of February to the 5th of March), no matter whether the month has 28, 29, 30 or 31 days - Calendar takes care of all of that for you, by encapsulating all those special rules into a fairly convenient black box.

    Now, Calendar might not be perfect (for example, it is sorely lacking an easy way to determine the *difference* between two given dates), and it's API might be somewhat clumsy, but believe me, it can save you a lot of headaches (or at least replaces them with some a lot lesser ones).



  • @Anonymouse said:

    if you add a "Month" to a date, you get the same day of the next month (e.g. going from the 5th of February to the 5th of March), no matter whether the month has 28, 29, 30 or 31 days

    So what is January 31st + one month?



  • @derula said:

    @Anonymouse said:
    if you add a "Month" to a date, you get the same day of the next month (e.g. going from the 5th of February to the 5th of March), no matter whether the month has 28, 29, 30 or 31 days

    So what is January 31st + one month?

     

    February 28th (29th if in a leap year). Documentation.



  • @Someone You Know said:

    @derula said:

    So what is January 31st + one month?
     

    February 28th (29th if in a leap year). Documentation.

    Rats; I was kind of hoping it would be March 3rd (2nd if in a leap year). I guess I don't fall under the rubric of "most users". Then again, I expect January 0 to be equivalent to December 31. That would be the set() method.

Log in to reply