When specifying a period is there ever a case where passing the number of the month as integer is preferred over passing two datetimes? For example GetTotalSumByMonth(int month) vs GetTotalSum(DateTime begin, DateTime end).

It seems to me that the second option has clear advantages since it is more generic and less ambiguous. You wouldn't be able to pass a month of last year in the first option since it's never given. And some people might think the number of the month starts with 0 instead of 1, like in Javascript or C, which could lead to confusion.

Are there any more pros or cons which might tip the scales?

  • So is the end parameter in GetTotalSum inclusive? Asking for a friend who is confused about your assertion that GetTotalSum is less ambiguous. – Peter M Jan 2 at 13:49
  • @PeterM Good point. The end parameter is inclusive, just like begin. This seems logical to me but I can see how it would create ambiguity for others. Do you have a remedy for this? – bdebaere Jan 2 at 13:52
  • 1
    The only remedy I can think of is descriptive naming of the function and/or parameters. But there are also trade offs between inclusive and exclusive EG exclusive makes it trivial to specify all of February regardless of what year it is in. – Peter M Jan 2 at 13:56
  • @PeterM This is a great point! Do you know of any downsides to the exclusive approach? – bdebaere Jan 2 at 14:03
  • 2
    If month is more meaningful in this scenario than date range, then pass a month parameter, just make it a proper user-defined type (i.e. enum or class) instead of an simply an int. – Erik Eidt Jan 2 at 16:10

I too would normally implement the date range method as you favour.

I guess one case would be where you aren't passing a single specific month, but doing some calculation for the same month over a number of years. ie "What's the usual sales figure for November?"

You can also see the advantage of not having to calculate the start and end of a month before calling the function.

Or, if I store my dates as text and use a regex to check the date, then I would be converting back from the input dates to a month number inside the function anyway, so you might as well pass the number.

Also, I have worked in places with concepts like "business month", which doesn't correspond to a calendar month but has a weird formula to exclude or include public holidays, or starts in April rather than January etc

The 0 vs 1 for January, is something you have to address, but this can also be true for inclusive vs exclusive date start and end.


There are a number of factors here to consider. The first thing I think you might want to consider is that Date-times and calendar dates are not really the same thing. It's tempting to think that calendar dates can always be represented with date-time structures but this isn't really the case and doing so can often create complications in logic.

A common issue is that a date-time implies some sort of time zone. If you are building a system that is used across time-zones, a date-time can be problematic if what you really mean is a calendar date. For example, let's say you use Zulu time (UTC) across everything. It could be Dec 31 UTC but Jan 1 in Australia. Which is the right date for your system? If it's the local calendar date, then you've created a problem for the users of this API to solve.

Another common issue that can arise is that the system may have rules such as "transactions after 5PM are logged on the next business day". Assuming you use exclusive date-time as the end of the period, what does it mean if I pass in midnight on Jan 1? Is an event that occurred at 6PM Dec 31, included? If not, the use of date-times becomes Now the code that calls this needs to encode these business rules into the calls and that gets spread throughout the code base. Then later, let's say the cutoff changes to 6PM. See the issue?

That you are asking this suggests to me that your requirements are based on calendar dates and not date-times. If that's correct, you should build an API that accommodates that directly. Note, however, that this doesn't proscribe providing another method that takes date times in addition to the simple month-based version. As you say, this is more generic and can be used in the solution for the month-based implementation.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.