CODEWITHSUNDEEP
javadateutcmilliseconds
Mr uNiQue
Mr uNiQue

Reputation: 29

Normalize the UTC date

I'm trying to read a code snippet but it does not make any sense to me.Please help me

 /**
 * To make it easy to query for the exact date, we normalize all dates that go into
 * the database to the start of the day in UTC time.
 *
 * @param date The UTC date to normalize
 *
 * @return The UTC date at 12 midnight
 */
 public static long normalizeDate(long date) {
    // Normalize the start date to the beginning of the (UTC) day in local time
    long retValNew = date / DAY_IN_MILLIS * DAY_IN_MILLIS;
    return retValNew;
}

This function accepts UTC converted local date in millis and now i don't know what is function is actually doing something commented as "Normalize the start date to the beginnig of the (UTC) day in local time" all this does not make any sense to me.Please anyone help me.

Upvotes: 0

Views: 1336

Answers (2)

Anonymous
Anonymous

Reputation: 86399

In Java and other programming languages a point in time is sometimes represented as a number of milliseconds since the so-called epoch of Jan 1, 1970 at 00:00:00 UTC excluding leap seconds. As the comment says, your method takes such a number and converts it to the start of the day (midnight) in UTC. For example a long value representing Mar 20, 2019 at 09:22:43 UTC will be converted to one representing Mar 20, 2019 at 00:00:00 UTC. If the value was only meant to represent a date, not a time of day, from the start, I would say that describing this as “normalizing” makes sense.

How does this work? date, the long variable holding the milliseconds, is first divided by the number of milliseconds in a day (I assume; I am reading DAY_IN_MILLIS as “1 day in milliseconds”). This gives the number of days since the epoch. The remainder from the division is discarded; you get only the whole days. Then when again multiplying by DAY_IN_MILLIS you are converting back to milliseconds. Since the epoch was defined as 00:00:00 on that day, you get 00:00:00 UTC on the same date that you had from the start. This works since UTC doesn’t have summer time (DST) and other time anomalies (it would not work in time zones that have).

And I admit that the “in local time” bit doesn’t make sense to me either. I suggest that it never made any sense.

Allow me to add that it’s poor code, though (even though you didn’t ask), which I also see as the reason why you needed to ask. Using the number of milliseconds since the epoch is generally discouraged, and conversion to start of day is better done through the standard API. Representing a point in time as a millisecond count is low-level and human-unfriendly. When looking at a number like 1553074048964 in your debugger or your log, you generally have no clue whether it’s wrong or right. Instead one should use an Instant, or for a date without time of day rather a LocalDate. An Instant prints as for example 2019-03-20T09:28:54.729Z. The time is in UTC, but even if you’re in a different time zone, it’s not too hard to get an idea of whether it’s wrong or right. Instant and LocalDate are classes from java.time, the modern Java date and time API. That API also has methods for all kinds of date and time operations including conversion to the start of day.

Link: Oracle tutorial: Date Time explaining how to use java.time.

Upvotes: 2

EchoMike444
EchoMike444

Reputation: 1692

I suppose that DAY_IN_MILLIS is 86400000

Because date is a long integer , when you divide by DAY_IN_MILLIS , you have in return a long integer without the decimal part .

So after when you multiply by DAY_IN_MILLIS you obtain a different number , that is rounded to a multiple of 86400000 .

2 dates belonging to the same UTC DAY will have the same value .

example for the math 

( 1 / 10 ) * 10   => 0 

( 9 / 10 ) * 10   => 0 

( 11 / 10 ) * 10   => 10

( 19 / 10 ) * 10   => 10

Upvotes: 0

Related Questions