commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Serge Knystautas <ser...@lokitech.com>
Subject Re: [lang] DateUtils round and truncate functionality with Calendar.AM_PM
Date Sun, 03 Aug 2003 23:54:25 GMT
Steven Caswell wrote:
> I don't know that rounding to AM_PM makes sense. I'm having a difficult time
> coming up with any rounding scenario that makes sense. I think it makes
> sense to say that the boundary is 12:00PM, and that times before that value
> cause round down, and times after that value cause round up.
> 
> But what does "round down" mean? What does "round up" mean? Maybe someone
> who has a use case for this functionality can provide a good suggestion.

Here's how I approached most of this logic... I treated truncating and 
rounding functions as eliminating all units below this order of specificity.

How to apply this to AM_PM?  Well, you'd keep the day unit and drop the 
hours unit.  So aside from the date, the two possible values are:
AM, 0 hours, 0 minutes, 0 sec, 0 ms.
PM, 0 hours, 0 minutes, 0 sec, 0 ms.

The first case is somewhat straight-forward... 0 hour is equivalent to 
12:00 AM.  The second case is a bit more confusing, but to be parallel, 
I would say it should be 12:00 PM.

So truncating would have 12:00 AM to 11:59:59.999 AM -> 12:00 AM, and 
12:00 PM to 11:59:59.999 PM -> 12:00 PM.  Rounding would then have 6:00 
PM to 5:59:59.999 AM -> 12:00 AM and 6:00 AM to 5:59:59.999 PM -> 12:00 
PM.  (I believe our convention is to always round up, so 6:00 AM -> 
12:00 PM).

Does this make sense?  Probably not a very commonly used case, but seems 
like we should have predictable behavior is someone passes this unit. 
Or conversely it could throw an exception with an unanticipated time unit?

-- 
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com/
p. 1.301.656.5501
e. sergek@lokitech.com



Mime
View raw message