bb.util
Class DateUtil.UnitTest

java.lang.Object
  extended by bb.util.DateUtil.UnitTest
Enclosing class:
DateUtil

public static class DateUtil.UnitTest
extends Object

See the Overview page of the project's javadocs for a general description of this unit test class.


Field Summary
private static Date date12345_12_31_23_59_59_999
           
private static Date date1994
           
private static Date date2004
           
private static Date date2004_11_28
           
private static Date date2004_11_30
           
private static Date date2004_12_01
           
private static Date date2004_12_24
           
private static Date date2004_12_30
           
private static Date date2004_12_31
           
private static Date date2004_12_31_23
           
private static Date date2004_12_31_23_59
           
private static Date date2004_12_31_23_59_59
           
private static Date date2004_12_31_23_59_59_999
           
private static Date date2004_6
           
private static Date date2005
           
private static Date date2005_01_02
           
private static Date date2005_12_31
           
private static Date date2006_12_31
           
private static Date date2014
           
private static Date date2114
           
private static Date date333BC
           
private static Date dateEpoch
           
private static Date dateFeb29OfLeapYear
           
private static Date dateFriday
           
private static Date dateMax
           
private static Date dateMin
           
private static Date dateSaturday
           
private static Date dateSunday
           
private static Date dayAfterLeapDay
           
private static Date fallBackDay
           
private static Date springForwardDay
           
 
Constructor Summary
DateUtil.UnitTest()
           
 
Method Summary
 void benchmark_getDayStart()
          Results on 2010-03-11 (2.5 GHz Xeon E5420 desktop, jdk 1.6.0_18 server jvm): n = 16 * 1024 getDayStart with ZERO cache: first = 12.227 us, mean = 1.028 us (CI deltas: -254.421 ps, +341.703 ps), sd = 1.188 us (CI deltas: -283.974 ns, +447.445 ns) WARNING: EXECUTION TIMES HAVE EXTREME OUTLIERS, SD VALUES MAY BE INACCURATE getDayStart with a perfectly sized cache: first = 30.391 us, mean = 71.381 ns (CI deltas: -62.114 ps, +65.987 ps), sd = 1.039 us (CI deltas: -143.734 ns, +196.449 ns) WARNING: SD VALUES MAY BE INACCURATE
 void benchmark_getTimeStamp()
          Results on 2010-03-11 (2.5 GHz Xeon E5420 desktop, jdk 1.6.0_18 server jvm): n = 16 * 1024 DateStringCache.format (for timeStampPattern) with ZERO cache: first = 15.570 us, mean = 1.995 us (CI deltas: -2.241 ns, +2.398 ns), sd = 6.630 us (CI deltas: -1.111 us, +1.534 us) WARNING: execution times have mild outliers, execution times may have serial correlation, SD VALUES MAY BE INACCURATE FORMAT CACHE MAY BE TOO SMALL: numberFormatPutFails = 40878080 > 0 State of this instance: sizeMax = 0, dateToString.size() = 0, stringToDate.size() = 0, numberFormatHits = 0, numberFormatMisses = 40878080, numberFormatPutFails = 40878080, numberParseHits = 0, numberParseMisses = 0, numberParsePutFails = 0 DateStringCache.format (for timeStampPattern) with a perfectly sized cache: first = 21.269 us, mean = 81.715 ns (CI deltas: -66.012 ps, +187.403 ps), sd = 1.652 us (CI deltas: -1.176 us, +1.787 us) WARNING: EXECUTION TIMES HAVE EXTREME OUTLIERS, SD VALUES MAY BE INACCURATE Good: there appear to be NO issues with this DateStringCache instance State of this instance: sizeMax = 16384, dateToString.size() = 16384, stringToDate.size() = 16384, numberFormatHits = 1174372352, numberFormatMisses = 16384, numberFormatPutFails = 0, numberParseHits = 0, numberParseMisses = 0, numberParsePutFails = 0
 void benchmark_isSameDayOfWeek()
          Results on 2010-03-11 (2.5 GHz Xeon E5420 desktop, jdk 1.6.0_18 server jvm): n = 16 * 1024 isExactDay with ZERO cache: first = 8.296 us, mean = 411.885 ns (CI deltas: -82.962 ps, +128.228 ps), sd = 823.586 ns (CI deltas: -252.314 ns, +573.272 ns) WARNING: EXECUTION TIMES HAVE EXTREME OUTLIERS, SD VALUES MAY BE INACCURATE isExactDay when cache has ~2 DateInfo per bin (suboptimal): first = 50.626 us, mean = 141.782 ns (CI deltas: -137.156 ps, +256.614 ps), sd = 2.082 us (CI deltas: -863.881 ns, +1.037 us) WARNING: EXECUTION TIMES HAVE EXTREME OUTLIERS, SD VALUES MAY BE INACCURATE The following issues were detected with the caching inside DateUtil: DateInfoCache: numberDateInfos = 16384 numberBinsWithInfos = 8192 numberBinsOverloaded = 8192 fraction of overloaded Bins (numberBinsOverloaded / numberBinsWithInfos) = 1.0 average number of DateInfos per DateInfoBin (considering only Bins with DateInfos) = 2.0 maxInfosInABin = 2 isExactDay when cache has ~1 DateInfo per bin (optimal): first = 25.749 us, mean = 127.110 ns (CI deltas: -47.740 ps, +98.323 ps), sd = 749.611 ns (CI deltas: -395.588 ns, +488.907 ns) WARNING: EXECUTION TIMES HAVE EXTREME OUTLIERS, SD VALUES MAY BE INACCURATE
 void benchmark_parseTimeStamp()
          Results on 2010-03-11 (2.5 GHz Xeon E5420 desktop, jdk 1.6.0_18 server jvm): n = 16 * 1024 DateStringCache.parse (for timeStampPattern) with ZERO cache: first = 10.790 us, mean = 4.114 us (CI deltas: -3.944 ns, +3.702 ns), sd = 7.742 us (CI deltas: -1.197 us, +1.543 us) WARNING: execution times have mild outliers, SD VALUES MAY BE INACCURATE PARSE CACHE MAY BE TOO SMALL: numberParsePutFails = 20430848 > 0 State of this instance: sizeMax = 0, dateToString.size() = 0, stringToDate.size() = 0, numberFormatHits = 0, numberFormatMisses = 0, numberFormatPutFails = 0, numberParseHits = 0, numberParseMisses = 20430848, numberParsePutFails = 20430848 DateStringCache.parse (for timeStampPattern) with a perfectly sized cache: first = 5.427 us, mean = 100.461 ns (CI deltas: -75.079 ps, +187.716 ps), sd = 1.796 us (CI deltas: -923.772 ns, +1.849 us) WARNING: EXECUTION TIMES HAVE EXTREME OUTLIERS, SD VALUES MAY BE INACCURATE Good: there appear to be NO issues with this DateStringCache instance State of this instance: sizeMax = 16384, dateToString.size() = 16384, stringToDate.size() = 16384, numberFormatHits = 0, numberFormatMisses = 0, numberFormatPutFails = 0, numberParseHits = 1174372352, numberParseMisses = 16384, numberParsePutFails = 0
 void test_calendarLeapSecondBehavior()
          Result of running this method on 2004/9/27: dateAfterLeapSecondFirst.getTime() % TimeLength.day = 0 which means that my machine did NOT take a leap second into account?
 void test_getXXX_fail1()
           
 void test_getXXX_fail2()
           
 void test_getXXX_pass()
           
 void test_getXXXStamp()
           
 void test_isXXX()
           
 void test_parseXXXStamp()
           
 void test_selfConsistencyOfManyMethods()
           
 
Methods inherited from class java.lang.Object
clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait
 

Field Detail

dateMin

private static final Date dateMin

dateMax

private static final Date dateMax

date333BC

private static final Date date333BC

dateEpoch

private static final Date dateEpoch

date1994

private static final Date date1994

date2004

private static final Date date2004

date2004_6

private static final Date date2004_6

date2004_11_28

private static final Date date2004_11_28

date2004_11_30

private static final Date date2004_11_30

date2004_12_01

private static final Date date2004_12_01

date2004_12_24

private static final Date date2004_12_24

date2004_12_30

private static final Date date2004_12_30

date2004_12_31

private static final Date date2004_12_31

date2004_12_31_23

private static final Date date2004_12_31_23

date2004_12_31_23_59

private static final Date date2004_12_31_23_59

date2004_12_31_23_59_59

private static final Date date2004_12_31_23_59_59

date2004_12_31_23_59_59_999

private static final Date date2004_12_31_23_59_59_999

date2005

private static final Date date2005

date2005_01_02

private static final Date date2005_01_02

date2005_12_31

private static final Date date2005_12_31

date2006_12_31

private static final Date date2006_12_31

date2014

private static final Date date2014

date2114

private static final Date date2114

date12345_12_31_23_59_59_999

private static final Date date12345_12_31_23_59_59_999

dateFriday

private static final Date dateFriday

dateSaturday

private static final Date dateSaturday

dateSunday

private static final Date dateSunday

dateFeb29OfLeapYear

private static final Date dateFeb29OfLeapYear

dayAfterLeapDay

private static final Date dayAfterLeapDay

springForwardDay

private static final Date springForwardDay

fallBackDay

private static final Date fallBackDay
Constructor Detail

DateUtil.UnitTest

public DateUtil.UnitTest()
Method Detail

test_calendarLeapSecondBehavior

public void test_calendarLeapSecondBehavior()
                                     throws Exception
Result of running this method on 2004/9/27: dateAfterLeapSecondFirst.getTime() % TimeLength.day = 0 which means that my machine did NOT take a leap second into account?

Throws:
Exception

test_isXXX

public void test_isXXX()
                throws Exception
Throws:
Exception

benchmark_isSameDayOfWeek

public void benchmark_isSameDayOfWeek()
Results on 2010-03-11 (2.5 GHz Xeon E5420 desktop, jdk 1.6.0_18 server jvm):

                        n = 16 * 1024
                                isExactDay with ZERO cache: first = 8.296 us, mean = 411.885 ns (CI deltas: -82.962 ps, +128.228 ps), sd = 823.586 ns (CI deltas: -252.314 ns, +573.272 ns) WARNING: EXECUTION TIMES HAVE EXTREME OUTLIERS, SD VALUES MAY BE INACCURATE

                                isExactDay when cache has ~2 DateInfo per bin (suboptimal): first = 50.626 us, mean = 141.782 ns (CI deltas: -137.156 ps, +256.614 ps), sd = 2.082 us (CI deltas: -863.881 ns, +1.037 us) WARNING: EXECUTION TIMES HAVE EXTREME OUTLIERS, SD VALUES MAY BE INACCURATE

                                The following issues were detected with the caching inside DateUtil:
                                DateInfoCache:
                                numberDateInfos = 16384
                                numberBinsWithInfos = 8192
                                numberBinsOverloaded = 8192
                                fraction of overloaded Bins (numberBinsOverloaded / numberBinsWithInfos) = 1.0
                                average number of DateInfos per DateInfoBin (considering only Bins with DateInfos) = 2.0
                                maxInfosInABin = 2

                                isExactDay when cache has ~1 DateInfo per bin (optimal): first = 25.749 us, mean = 127.110 ns (CI deltas: -47.740 ps, +98.323 ps), sd = 749.611 ns (CI deltas: -395.588 ns, +488.907 ns) WARNING: EXECUTION TIMES HAVE EXTREME OUTLIERS, SD VALUES MAY BE INACCURATE
 


test_getXXX_pass

public void test_getXXX_pass()
                      throws Exception
Throws:
Exception

test_getXXX_fail1

public void test_getXXX_fail1()
                       throws Exception
Throws:
Exception

test_getXXX_fail2

public void test_getXXX_fail2()
                       throws Exception
Throws:
Exception

test_selfConsistencyOfManyMethods

public void test_selfConsistencyOfManyMethods()
                                       throws Exception
Throws:
Exception

benchmark_getDayStart

public void benchmark_getDayStart()
Results on 2010-03-11 (2.5 GHz Xeon E5420 desktop, jdk 1.6.0_18 server jvm):

                        n = 16 * 1024
                                getDayStart with ZERO cache: first = 12.227 us, mean = 1.028 us (CI deltas: -254.421 ps, +341.703 ps), sd = 1.188 us (CI deltas: -283.974 ns, +447.445 ns) WARNING: EXECUTION TIMES HAVE EXTREME OUTLIERS, SD VALUES MAY BE INACCURATE
                                getDayStart with a perfectly sized cache: first = 30.391 us, mean = 71.381 ns (CI deltas: -62.114 ps, +65.987 ps), sd = 1.039 us (CI deltas: -143.734 ns, +196.449 ns) WARNING: SD VALUES MAY BE INACCURATE
 


test_getXXXStamp

public void test_getXXXStamp()
                      throws Exception
Throws:
Exception

benchmark_getTimeStamp

public void benchmark_getTimeStamp()
Results on 2010-03-11 (2.5 GHz Xeon E5420 desktop, jdk 1.6.0_18 server jvm):

                        n = 16 * 1024
                                DateStringCache.format (for timeStampPattern) with ZERO cache: first = 15.570 us, mean = 1.995 us (CI deltas: -2.241 ns, +2.398 ns), sd = 6.630 us (CI deltas: -1.111 us, +1.534 us) WARNING: execution times have mild outliers, execution times may have serial correlation, SD VALUES MAY BE INACCURATE
                                        FORMAT CACHE MAY BE TOO SMALL: numberFormatPutFails = 40878080 > 0
                                        State of this instance: sizeMax = 0, dateToString.size() = 0, stringToDate.size() = 0, numberFormatHits = 0, numberFormatMisses = 40878080, numberFormatPutFails = 40878080, numberParseHits = 0, numberParseMisses = 0, numberParsePutFails = 0

                                DateStringCache.format (for timeStampPattern) with a perfectly sized cache: first = 21.269 us, mean = 81.715 ns (CI deltas: -66.012 ps, +187.403 ps), sd = 1.652 us (CI deltas: -1.176 us, +1.787 us) WARNING: EXECUTION TIMES HAVE EXTREME OUTLIERS, SD VALUES MAY BE INACCURATE
                                        Good: there appear to be NO issues with this DateStringCache instance
                                        State of this instance: sizeMax = 16384, dateToString.size() = 16384, stringToDate.size() = 16384, numberFormatHits = 1174372352, numberFormatMisses = 16384, numberFormatPutFails = 0, numberParseHits = 0, numberParseMisses = 0, numberParsePutFails = 0
 


test_parseXXXStamp

public void test_parseXXXStamp()
                        throws Exception
Throws:
Exception

benchmark_parseTimeStamp

public void benchmark_parseTimeStamp()
Results on 2010-03-11 (2.5 GHz Xeon E5420 desktop, jdk 1.6.0_18 server jvm):

                        n = 16 * 1024
                                DateStringCache.parse (for timeStampPattern) with ZERO cache: first = 10.790 us, mean = 4.114 us (CI deltas: -3.944 ns, +3.702 ns), sd = 7.742 us (CI deltas: -1.197 us, +1.543 us) WARNING: execution times have mild outliers, SD VALUES MAY BE INACCURATE
                                        PARSE CACHE MAY BE TOO SMALL: numberParsePutFails = 20430848 > 0
                                        State of this instance: sizeMax = 0, dateToString.size() = 0, stringToDate.size() = 0, numberFormatHits = 0, numberFormatMisses = 0, numberFormatPutFails = 0, numberParseHits = 0, numberParseMisses = 20430848, numberParsePutFails = 20430848

                                DateStringCache.parse (for timeStampPattern) with a perfectly sized cache: first = 5.427 us, mean = 100.461 ns (CI deltas: -75.079 ps, +187.716 ps), sd = 1.796 us (CI deltas: -923.772 ns, +1.849 us) WARNING: EXECUTION TIMES HAVE EXTREME OUTLIERS, SD VALUES MAY BE INACCURATE
                                        Good: there appear to be NO issues with this DateStringCache instance
                                        State of this instance: sizeMax = 16384, dateToString.size() = 16384, stringToDate.size() = 16384, numberFormatHits = 0, numberFormatMisses = 0, numberFormatPutFails = 0, numberParseHits = 1174372352, numberParseMisses = 16384, numberParsePutFails = 0