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. [EMAIL PROTECTED]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to