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.
–
CaffGeekMay 18 '12 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.
–
Onorio CatenacciMay 18 '12 at 16:15

1

@downvoter Can you explain the downvote so that maybe I can reconstruct my question if something wasn't right?
–
David PetermanMay 18 '12 at 18:16

5

@DavidPeterman, some people are just idiots and down-vote everything..
–
CaffGeekMay 18 '12 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.
–
Clockwork-MuseMay 18 '12 at 20:46

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 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.
–
AlexWebrMay 18 '12 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.
–
Ben HockingMay 18 '12 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.
–
CalebMay 18 '12 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
–
mattnzMay 19 '12 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.
–
CalebMay 19 '12 at 13:20

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?
–
David PetermanMay 18 '12 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.
–
MPelletierMay 18 '12 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).
–
David PetermanMay 18 '12 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.
–
MPelletierMay 18 '12 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.
–
MPelletierMay 18 '12 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
else
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.
–
TrebMay 18 '12 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.
–
Armen B.May 18 '12 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?
–
CaffGeekMay 18 '12 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.
–
MyNameIsZeroMay 22 '12 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.
–
Armen B.May 22 '12 at 18:54

@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****
–
CaffGeekMay 18 '12 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.
–
Scott WhitlockMay 18 '12 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 DiploMay 18 '12 at 19:25

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.