The implementation absolutely does matter. Querying against one database or another is very different depending on how that database stores date / time values. I suggest you edit your question and make it specific for the technologies that you are using. Show some code if you can.
In general though, you are mixing two concepts and you should probably try to separate them mentally.
The moment something happened, an event time, can be measured by a DateTime combined value - represented as either UTC, or as a value that is offset from UTC where the offset is known. This is often referred to as "Instantaneous Time", "Universal Time", or "Physical Time".
The values that we give to dates and times when talking about them locally, such as "Today", "Yesterday", or "March 29, 2013". Even when we have a time, we are talking about a fraction of a day on a calendar. This is often referred to as "Calendar Time", "Local Time" or "Civil Time".
You can always query and do math with Instantaneous Time. It's unambiguous. However, the concept of "Today" is meaningless. There is no observer to mark the end of one day and the start of the next. (One could argue that the observer is in London, but that's not true during BST.)
Calendar Time is only suitable for querying or math when you have day-level precision and only one observer. So it usually makes a poor representation of something meant to be universal, like an event.
Let's go back to your original question. You said:
I want to query everything between 23-mar-2013 to 24-mar-2013
Right there - you have a problem. What is the context? Who's calendar dates are you talking about? Even though you said March 23, you probably don't mean March 23rd at midnight UTC to March 24th at midnight UTC. You probably mean some other calendar's midnights.
Keep in mind that not every day is 24 hours in length. When time zones switch on and off of daylight savings time (or summer time), the days could be 23 hours or 25 hours in length.
So what to do? First, you need a Time Zone database (like the IANA/Olson/TZ/TZDB/ZoneInfo database for example) Here is one implemented in Ruby.
Now, you need to to know the local time zone of the user. That is - the person that is asking the question that you are showing the query results to. That will involve your own application logic, maybe a selector or picker. If this is a web app, you might want to look at this map-based timezone picker, or at jsTimeZoneDetect.
You should always store events with instantaneous time. Let's just say you store events as UTC (although you might use an offset, we'll ignore that for now).
So you need to know for the date range that the user wants, what UTC times do the start and end dates of your query map to? For example, say we are in India using the Asia/Calcutta time zone. We would convert 23-mar-2013 00:00 - 24-mar-2013 00:00, to the UTC equivalent 22-mar-2013 18:30 - 23-mar-2013 18:30.
Then you can use those UTC DateTime values to query the database.
When you return the results to your user, you will probably want to convert UTC back to local time so they understand the results they are looking at.
You should also read the many great suggestions in this post.
