So I have a function that takes two dates. The SQL query gets all the results between the two dates. I currently have my function setup as such:

function myFunc(start, end)

Where start is the most recent date and end is the oldest date.

Is this intuitive/correct or is there another naming/ordering convention I should be using?

  • 8
    It doesn't matter, you know you want them one way or the other, the user can still mess up. So just fix it at the start of your function by comparing them to one another. Assign the older value to end, the newer value to start, and carry on. Personally, I think you have them backwards, but that's just me, and really, doesn't matter.
    – CaffGeek
    May 18, 2012 at 16:04
  • 21
    I would find that convention counter-intuitive. When considering a span of dates it's intuitive to have the "start" date be the oldest date and the "end" date be the most recent. May 18, 2012 at 16:15
  • 1
    @downvoter Can you explain the downvote so that maybe I can reconstruct my question if something wasn't right? May 18, 2012 at 18:16
  • 5
    @DavidPeterman, some people are just idiots and down-vote everything..
    – CaffGeek
    May 18, 2012 at 18:37
  • 2
    Also, when dealing with dates, you should consider inclusive lower bounds, and exclusive upper bounds. It's much easier to get the start of the month than the end of the month, for example. May 18, 2012 at 20:46

9 Answers 9


Typically, you'd think that start <= end, so not really. Consider renaming it to give a hint to the business logic you are trying to implement.


In the normal course of business, time only works in one direction, and "start" generally comes before "end". I'd be inclined to make "start" the earliest date in the range and "end" the latest. But if your query simply searches for anything between the two dates and doesn't depend on them being in order (which would make for a more robust, easier to use function) then it shouldn't really matter what you call them.

It's obviously easy to add that feature to your function. Just have the function compare the two dates and swap them if they're not already in the order that it requires. You might also give the parameters more generic names like date1 and date2 to help convey to users that they just need to supply two dates and not worry about the order.

  • 1
    +1 for But if your query simply searches for anything between the two dates and doesn't depend on them being in order - this is good to consider.
    – user41310
    May 18, 2012 at 19:43
  • 1
    Your advice to simply search for anything between the two dates (regardless of order) can often be the right thing, but sometimes might not be. There are cases where a start date after the end date means that you don't want any dates whatsoever. May 18, 2012 at 21:12
  • 1
    @BenHocking No argument there. The order of the dates could also indicate the way you want the results ordered. I'm not suggesting that enforcing an order is always appropriate; I'm just trying to help the OP, and I can only go on what little he tells us about the issue: The SQL query gets all the results between the two dates... I have to believe that the OP will be smart enough to know whether enforcing a certain order is appropriate for his situation.
    – Caleb
    May 18, 2012 at 21:28
  • -1 "...it shouldn't really matter what you call them.".Unclear, ambiguos and poorly though out names..are at best lazy and unprofession un-professional
    – mattnz
    May 19, 2012 at 6:38
  • @mattnz Yes, I wouldn't recommend goopflarg and beezlebub as names. But if the function can tell which date it wants to use as the beginning of the range and which as the end, it doesn't matter which one you call start and which you call end, and other reasonable names like date1 and date2 work equally well.
    – Caleb
    May 19, 2012 at 13:20

Why not just name them what they are? That would seem to be the most intuitive to me.

function myFunc(recentDate, oldDate)

You are defining a time span. A time span has a start and an end (or begin and end). It doesn't have a "most recent" and "least recent" because this calls to the notion of "present", which is not relevant.

Further adding to the notion of "no time like the present", the start and end can be both in the past, both in the future, or one before and one after the present. Suddenly "most recent" becomes a lot more complicated.

  • With this in mind, what would be your solution to the question then? How do you convey this to other developers in your function's arguments? May 18, 2012 at 17:40
  • 4
    Simply "StartDate", "EndDate", and good documentation. There is a case to be made for documentation. A well made API has appropriate documentation. Furthermore, if you want to get cocky, throw an Exception if EndDate < StartDate, and document that too.
    – MPelletier
    May 18, 2012 at 18:05
  • I completely agree with you, but I think my question was geared more towards the normal conventions and what would be intuitive. I was trying to make it easy for the developer so that they didn't have to go looking in documentation. To put it short, I didn't want to make it function(haystack, needle) when the known convention is function(needle, haystack). May 18, 2012 at 18:12
  • I agree with the desire to make something adequate and clear. I'm working with an old code base where any notion of "first" and "last" are labelled "a" and "z"... "Start" and "End" sound much more natural.
    – MPelletier
    May 18, 2012 at 18:20
  • 1
    There's also a case to be made for reading left to right. The order goes that way in more languages than the reverse. Both human and programming languages.
    – MPelletier
    May 18, 2012 at 18:22

I think start shouldn't be used. To Start and to Stop, not to Start and End. I think you can use Begin and End together but that can be confusing again from which point of reference you looking at Begin.

I use function(FROM, TO) for more correct English perhaps. But in any case, you should place a wrapper logic in your function which sets the earliest date properly:

if FROM is earlier than TO 
 t_earliestDate = FROM
 t_latestDate = TO
 t_earliestDate = TO
 t_latestDate = FROM
  • +1 for FROM and TO. But I disagree with your wrapper logic, if FROM is greater than TO the function should fail.
    – Treb
    May 18, 2012 at 17:12
  • 1
    Your right, but what if the function's main goal is to provide for example data given a range of time, then FROM and TO can be interchangeable since the range is the important drive.
    – ArmenB
    May 18, 2012 at 17:23
  • @Treb, no need for it to fail if you're just looking for a range. Why fail when it really does not matter?
    – CaffGeek
    May 18, 2012 at 17:34
  • 1
    @Trab: that would imply a lot of type checking and value validation. "Design by contract" says (among other things) that you define a contract (protocol) for your functions and their callers are responsible to follow the protocol. In some cases it makes sense to protect some pieces of code (i.e. avoid stuff that would mess the system) but I would advice against doing it always.
    – MyName
    May 22, 2012 at 8:08
  • 1
    exactly, BUT if it is a vector, then it matters. So depends on the situation - not everything is black and white.
    – ArmenB
    May 22, 2012 at 18:54

Really, who cares. It's a date range, you want everything between the two dates. No matter the names, someone will screw up their usage.

And your code wants start to be the recent date, and end to be the oldest.

So, at the start of your function switch them around if they are backwards.

var tmpStart = start;
var tmpEnd = end;
start = (tmpStart < tmpEnd) ? tmpEnd : tmpStart;
end   = (tmpStart < tmpEnd) ? tmpStart : tmpEnd;

I personally would use from, and to instead of start and end.

  • 4
    Your swapping logic is flawed. If they are ordered wrong, start will be set to end, and the original value of start will be lost. May 18, 2012 at 17:10
  • @BenjaminLindley, Good catch! Hmm...I better go double check my code that I copied this from... It appears mine worked because it was arguments in a constructor being assigned to properties, so the original argument value was never being re-assigned ****phew****
    – CaffGeek
    May 18, 2012 at 17:35
  • This only works for absolute dates. You want to be careful if you copied this logic to something like "give me the sales from November to February for last year (or last x years)". In that case, I definitely don't want you to use February as the earliest and November as the most recent. May 18, 2012 at 17:41
  • 4
    I'd rather throw a ArgumentOutOfRange type exception than try and guess what the caller intended. Trying to be clever inevitably needs to trouble IMO.
    – Dan Diplo
    May 18, 2012 at 19:25
  • @ScottWhitlock What devilish code are you working on that passes dates like that instead of either a sane datetime object or at least 'yyyy-mm-dd'?
    – Izkata
    May 18, 2012 at 19:42

You can create a wrapping type (class or structure) called DateInterval. A DateInterval is something that is defined by a start date (earliest) and an end date (latest).

Then, you change your original function to receive a single argument: the DateInterval.

I would say this leads to a more natural design - those two dates to not make sense without each other. It also reduces function argument count. Also, I think it reduces the ambiguity, since most people will probably recognise a DateInverval as a pair.


In a well planned piece of code, all these issues need to be adressed:

  • Dates only in the past.
  • Dates only in the future.
  • Dates that bridge the current time.
  • Requests with only one value:. From then to now, or now to then.
  • Requests out of order
  • Requests with string input: yesterday
  • Requests with only partial values: just a year, or just a month and year; Second Quarter of fiscal 2012.

Not all will make sense for your application, but they should be thought about during design. Some will throw errors, some will auto correct. How you label the inputs will depend on the business logic, is this an API, or are you labeling the fields on the GUI.

Also remember to document so it is clear the the developer or user what is happening.


It depends on how you're using it in your app and/or business rules. If they think of these date ranges as "Start with this date and go back in time to another date", you're all set. Programmers or dbas who are going to use this function will consider the start date as the earliest date and the end to be most recent. I would think this would be chronological.

You indicated the function will run a sql query with a date range "between" these two dates. The BETWEEN operator would look for a date range: >= the begin date AND <= the end date. Users may not know how you're doing this in the function code, but that just seems consistent/standard.

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