Refactoring or removal of isDateTimeOk

[uraimo]

Currently the utils bundle contains the following date check code:

public static final long DEFAULT_INITIAL_TIME = 1288566000000l; // 00:00 1st November 2010 (GMT+1)

public static boolean isDateTimeOk(long timeInMillis) {
     return timeInMillis > DateUtils.DEFAULT_INITIAL_TIME;
}

This check is used to verify that the date is "valid" (or better, admissible) in various places and can stop the startup phase of certain bundles (successive attempts will be made in this case):

./jemma.osgi.ah.hac.lib/src/main/java/org/energy_home/jemma/ah/hac/lib/internal/TimeServerCluster.java:     if (!isDateTimeOk()) {
./jemma.osgi.ah.energyathome/src/main/java/org/energy_home/jemma/internal/ah/eh/esp/ESPConfiguration.java:          if (!DateUtils.isDateTimeOk())
./jemma.osgi.utils/src/main/java/org/energy_home/jemma/osgi/utils/Activator.java:       if (!dateTimeObject.isDateTimeOk()) { 
./jemma.osgi.utils/src/main/java/org/energy_home/jemma/osgi/utils/Activator.java:                   if (DateUtils.isDateTimeOk()) {
./jemma.osgi.ah.hap.client/src/main/java/org/energy_home/jemma/osgi/ah/hap/client/HapServiceComponent.java:     if (dateTimeService == null || !dateTimeService.isDateTimeOk())

At a first look, this is an area worthy of refactoring imho, because while this check prevents a date like 1st january 1970 (unix epoch, this cover the condition where a gateway has not yet got the correct date using ntp) from being used in the platform (can't comment on the possible side-effects of using a wrong date), the sequence of events that a failure of that check leads to it's not clear.

I'd say this is something to consider for future refactoring (centralize the check in a single component with a deterministic behaviour) or complete removal.