commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 31395] New: - DateUtils.truncate oddity at the far end of the Date spectrum
Date Fri, 24 Sep 2004 07:17:53 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=31395>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=31395

DateUtils.truncate oddity at the far end of the Date spectrum

           Summary: DateUtils.truncate oddity at the far end of the Date
                    spectrum
           Product: Commons
           Version: 2.0 Final
          Platform: PC
        OS/Version: Windows NT/2K
            Status: NEW
          Severity: Minor
          Priority: Other
         Component: Lang
        AssignedTo: commons-dev@jakarta.apache.org
        ReportedBy: mpo@apache.org


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=

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message