This has two parts: (1) Interfacing with user shall be cognitive. Something which user can relate to his natural thought process.
E.g.: In a banking system, if a user goes to a banker to get his bank statement. He will say "give me statement from 11th October 2015 to 23rd October 2015". This clearly communicates in simplified language that user is interested in bank statement from 11th October to 23rd October. If banker now does not return data of 23rd October, it will be a surprise for user. Banker can inform every user that To date is exclusive, so if you need statement till 23rd October you should come and tell me "give me statement from 11th October to 24th October". I believe a user will immediately reply => If I need statement only till 23rd October, why shall I communicate 11th October to 24th October. If you still insist, next time the user will come and say "give me statement from 11th October to 24th October with 24th exclusive". System just made it harder for user to communicate with banker. (2) Implementation to achieve cognitive behaviour With To date inclusive, banker needs to make sure that it gives all transaction records for 23rd October 2015 (To date) at the finest granularity available with the bank. This will satisfy users requirement without any element of surprise. If the finest granularity is millisecond. It will have a higher limit to it which is 999 in most of the systems. Banker will fetch all partitions until higher limit of finest granularity for 23rd October and return the statement to user. If there was a leap second/millisecond, it is upto the banker to handle and give data for it. When a user wants statement from 11th October to 23rd October, user should not worry about the leap second/millisecond which happened on any of the days from 11th October to 23rd October (inclusive). Regards, Himanshu On Wed, Aug 5, 2015 at 3:16 PM, amareshwarisr . <[email protected]> wrote: > I prefer time-range end date to be exclusive of the end date, because of > the following reasons: > > 1. Giving a month range end as start of next month is easy, as you need not > remember and get confused with number of days in month : 30, 31, 28/29 (in > february leap year) - wont miss ending days because of mistakes. > > 2. When you are giving a any range, you need not worry about what > granularity should the time be specified. > For ex, for including time upto 2015-08-01 05th. > > Should user specify the following with inclusive ranges? > > 2015-08-01-04 (would be correct, assuming whole of 4 th hour will be > included) > > 2015-08-01-04-59 (would be correct, but what if there is leap second :p ) > > 2015-08-01-04-59-000 (wrong, would include only 000th milli second and > not others) > > 2015-08-01-04-59-999 (not sure if we will have leap milli seconds) > > Looking forward to see other arguments on making timerange end date > inclusive. > > Thanks > Amareshwari > > On Wed, Aug 5, 2015 at 2:50 PM, Rajat Khandelwal <[email protected]> > wrote: > > > Currently the time_range_in clause is inclusive of the start date and > > exclusive of the end date. i.e. time_range_in(time_dimension, date1, > date2) > > translates to date1<=time_dimension<date2 > > > > Recently there have been multiple discussions regarding this approach in > > our internal forums at InMobi. There have been arguments that as an > > analytics system, it should accept end date inclusive. Starting this > thread > > to know opinions of other people regarding both approaches. I'm defining > > and briefly discussing both approaches below: > > > > Approach 1: End date exclusive. > > Disclaimer: I personally prefer this approach and would shamelessly argue > > in its favor. I'll give links to some of the articles that I very much > > agree with (no need to reinvent the wheel of argument) > > > > 1. Views of Anders Kaseorg, MIT PhD student in CS; Cofounder of > Ksplice, > > Inc > > < > > > https://www.quora.com/Why-are-Python-ranges-half-open-exclusive-instead-of-closed-inclusive/answer/Anders-Kaseorg > > > > > 2. Views of Edgar Dijkstra, Creator of Dijkstra's algorithm > > <http://www.cs.utexas.edu/users/EWD/ewd08xx/EWD831.PDF> > > 3. Both arguments are for generic ranges. I believe time range is > also a > > range and don't see why we need to handle that as a special case. > > > > > > Approach 2: End date inclusive. > > > > 1. Lens query language is a bit like sql and the BETWEEN clause in sql > > is inclusive of both start and end date. > > 2. Most analytic systems --- including google analytics --- follow > this > > convention > > > > > > I'm posting the question on a bigger forum > > < > > > https://www.quora.com/Should-Time-ranges-in-an-analytical-system-be-half-open-or-closed > > > > > as well in hopes of getting more opinions. I request everyone to post > their > > views here regarding both approaches. > > > > Regards > > > -- _____________________________________________________________ The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. It may contain confidential or legally privileged information. If you are not the intended recipient you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the contents of this information is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by responding to this email and then delete it from your system. The firm is neither liable for the proper and complete transmission of the information contained in this communication nor for any delay in its receipt.
