[LANG-24] [lang] DateUtils.truncate oddity at the far end of the Date spectrum

• Type: Bug
• Status: Closed
• Priority: Minor
• Resolution: Fixed
• Affects Version/s: 2.0
• Fix Version/s: 2.1
• Component/s: lang.time.*

Environment

Operating System: All
Platform: PC

• Bugzilla Id: 31395
• Assignee: Unassigned
• Reporter: Marc Portier
• Created: 24/Sep/04 14:17
• Updated: 16/Dec/09 08:51
• Resolved: 16/Dec/09 08:51

Description

I'm assuming that the goal of the truncate() method in
org.apache.commons.lang.time.DateUtils is to be a shorthand for the otherwise
cumbersome java.util.Calendar operations of setting all lower fields to 0.

In other words, the following 2 methods are (by me) expected to yield the same:

private Date commonsTruncate(Date date)

{ return DateUtils.truncate(date, Calendar.DATE); }

private Date truncate(Date date)

{ Calendar c = Calendar.getInstance(); c.setTime(date); c.set(Calendar.HOUR_OF_DAY, 0); c.set(Calendar.MINUTE, 0); c.set(Calendar.SECOND, 0); c.set(Calendar.MILLISECOND, 0); return c.getTime(); }

This is generally the case, except for the very pathological case of the
ultimate biggest date Java allows you to make:

Date endOfTime = new Date(Long.MAX_VALUE);
// fyi: Sun Aug 17 07:12:55 CET 292278994 – 807 millis

commons-result: Sun Aug 17 02:00:00 CEST 292278994
// commonsTruncate(endOfTime)
handmade-result: Sun Aug 17 00:00:00 CEST 292278994
// truncate(endOfTime)
(mind the 2h difference)

Another odd observation concerning this special date is that the commons-result
WILL match the other one if we allow the commons truncate to operate on the
result again:

commons-double-truncate-result:
Sun Aug 17 00:00:00 CEST 292278994
// truncate(truncate(endOfTime))

(which is somewhat another surprise: one would expect truncation not to change a
Date that was already truncated)

my (totally wild) guess is that this is related to timezone and DST issues
fact being that similar effects are seen on all Date's pointing to a moment in
the last 2hours of the Date spectrum.

I understand that this is a very hypothetical issue, nevertheless.

kind regards,
-marc=