getActualMinimum with HOUR as argument of Calendar returns 12 in Java

Question

I'm trying to set the time of the calendar by calling the method calendar.set(Calendar.HOUR, calendar.getActualMinimum(Calendar.HOUR)); But getActualMinimum(Calendar.HOUR) returns 12 instead of 0.

Answer 1

Try using Calendar.HOUR_OF_DAY .

Answer 2

tl;dr

Use java.time classes rather than the troubled legacy classes.

To get the first moment of a day, call LocalDate.atStartOfDay( ZoneId ).

LocalDate.now(                       // Represent the date alone, without time-of-day and without time zone.
    ZoneId.of( "Africa/Tunis" )      // Specify the time zone in which to determine the current date.
)
.withDayOfYear( 1 )                  // Or `.withDayOfMonth(1)` or `.with( TemporalAdjusters.previousOrSame( DayOfWeek.MONDAY) )`.
.atStartOfDay(                       // Determine the first moment of the day on that particular date in that particular zone.
    ZoneId.of( "Africa/Tunis" )
)                                    // Returns a `ZonedDateTime` object.
.toInstant()                         // Same moment, as seen in UTC.
.toEpochMilli()                      // Extract a count of milliseconds since the epoch reference of 1970-01-01T00:00:00Z. 

java.time

You are using troublesome old date-time classes that are now legacy, supplanted by the java.time classes.

Getting the current date and time requires a time zone. For any given moment, the date and time vary around the globe by zone.

ZoneId z = ZoneId.of( "America/Montreal" ) ;
ZonedDateTime zdt = ZonedDateTime.now( z ) ;

Extract the date-only portion of that date-with-time.

LocalDate ld = zdt.toLocalDate() ;

From that date, let java.time determine the first moment of the day. Never assume the day starts at 00:00:00. Anomalies such as Daylight Saving Time (DST) mean the day may start at another time such as 01:00:00.

The java.time classes use immutable objects. Rather than alter a property on an object (“mutate”), a fresh new object is created based on values of the original.

ZonedDateTime zdtResult = null ;

For your switch statement, use existing ChronoUnit enum. Because of an odd technical issue, the switch statement cannot use a qualified enum name. So we must use YEARS rather than ChronoUnit.YEARS, for example, as the switch variable. Use a static import to access the enum.

import static java.time.temporal.ChronoUnit ;
…

switch ( unit ) {
    case YEARS : 
        zdtResult = ld.withDayOfYear( 1 )
                      .atStartOfDay( z ) ;
        break;

    case MONTHS : 
        zdtResult = ld.withDayOfMonth( 1 )
                      .atStartOfDay( z ) ;
        break;

    case WEEKS : 
        zdtResult = ld.with( TemporalAdjusters.previousOrSame( DayOfWeek.MONDAY) )
                      .atStartOfDay( z ) ;
        break;

    default: …
}

From the resulting ZonedDateTime, extract an Instant object to see that same moment in UTC.

Instant instant = zdtResult.toInstant() ;

Your Question’s goal seems to be a count of milliseconds from the epoch reference of first moment of 1970 in UTC. I strongly suggest against using a mere long integer to track date-time values. Makes debugging and tracing troublesome, with bugs likely to escape notice. Pass around and store Instant objects instead.

But if you insist on the count, here's the code. Beware of data loss, as an Instant has a resolution of nanoseconds, so this call ignores any existing microseconds or nanoseconds.

long millisSinceEpoch = instant.toEpochMillis() ;

Notice how using java.time makes for code that is shorter, neater, and much more readable.

---

About java.time

The java.time framework is built into Java 8 and later. These classes supplant the troublesome old legacy date-time classes such as java.util.Date, Calendar, & SimpleDateFormat.

The Joda-Time project, now in maintenance mode, advises migration to the java.time classes.

To learn more, see the Oracle Tutorial. And search Stack Overflow for many examples and explanations. Specification is JSR 310.

You may exchange java.time objects directly with your database. Use a JDBC driver compliant with JDBC 4.2 or later. No need for strings, no need for java.sql.* classes.

Where to obtain the java.time classes?

• Java SE 8, Java SE 9, Java SE 10, and later
  • Built-in.
  • Part of the standard Java API with a bundled implementation.
  • Java 9 adds some minor features and fixes.
• Java SE 6 and Java SE 7
  • Much of the java.time functionality is back-ported to Java 6 & 7 in ThreeTen-Backport.
• Android
  • Later versions of Android bundle implementations of the java.time classes.
  • For earlier Android (<26), the ThreeTenABP project adapts ThreeTen-Backport (mentioned above). See How to use ThreeTenABP….

The ThreeTen-Extra project extends java.time with additional classes. This project is a proving ground for possible future additions to java.time. You may find some useful classes here such as Interval, YearWeek, YearQuarter, and more.