commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Serge Knystautas <>
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
Lokitech >> software . strategy . design >>
p. 1.301.656.5501

View raw message