Time consts in Java?
Solution 1
Joda-Time contains classes such as Days, which contain methods such as toStandardSeconds(). So you can write:
int seconds = Days.ONE.toStandardSeconds();
although it seems a little verbose, and perhaps is only useful for more complex scenarios such as leap years etc.
Solution 2
I would go with java TimeUnit if you are not including joda-time in your project already. You don't need to include an external lib and it is fairly straightforward.
Whenever you need those "annoying constants" you usually need them to mutliply some number for cross-unit conversion. Instead you can use TimeUnit to simply convert the values without explicit multiplication.
This:
long millis = hours * MINUTES_IN_HOUR * SECONDS_IN_MINUTE * MILLIS_IN_SECOND;
becomes this:
long millis = TimeUnit.HOURS.toMillis(hours);
If you expose a method that accepts some value in, say, millis and then need to convert it, it is better to follow what java concurrency API does:
public void yourFancyMethod(long somePeriod, TimeUnit unit) {
int iNeedSeconds = unit.toSeconds(somePeriod);
}
If you really need the constants very badly you can still get i.e. seconds in an hour by calling:
int secondsInHour = TimeUnit.HOURS.toSeconds(1);
Solution 3
Java 8 / java.time solution
As an alternative to TimeUnit
, you might for some reason prefer the Duration class from java.time package:
Duration.ofDays(1).getSeconds() // returns 86400;
Duration.ofMinutes(1).getSeconds(); // 60
Duration.ofHours(1).toMinutes(); // also 60
//etc.
Additionally, if you would go deeper and have analyzed how Duration.ofDays(..) method works, you would see the following code:
return create(Math.multiplyExact(days, SECONDS_PER_DAY), 0);
where SECONDS_PER_DAY
is a package protected static constant from LocalTime class.
/**
* Seconds per day.
*/
static final int SECONDS_PER_DAY = SECONDS_PER_HOUR * HOURS_PER_DAY;
//there are also many others, like HOURS_PER_DAY, MINUTES_PER_HOUR, etc.
I think it is safe to assume that if there would be any package, which would defined "all the annoying time constants like miliseconds/seconds/minutes" as you call them, I believe Java SDK Developers would have use them.
Why are this LocalTime
constants package protected and not public that is a good question, I believe there is a reason for that. For now it looks like you really have to copy them and maintain on your own.
Solution 4
If on android, I suggest:
DateUtils.SECOND_IN_MILLIS
DateUtils.MINUTE_IN_MILLIS
DateUtils.HOUR_IN_MILLIS
DateUtils.DAY_IN_MILLIS
DateUtils.WEEK_IN_MILLIS
DateUtils.YEAR_IN_MILLIS
Solution 5
The Java TimeUnit seems to be what you want
kanso
I've had my B.Sc in software engineering at 2008, and since then had the privlige to work at big corportaes (Intel Research, Thomson Reuters), build the backbones of amazing startups (Outbrain, Ginger), complete my thesis, and keep learning new stuff all the time. I've done research in c and Java, backend in Java and Node, NLP in Groovy, scala and some C# (Hate it, sorry), some web in Angular, toyed around with native android apps and was a part of building an ionic cross-platform app. I love tera-incognita, and rather walk the bleeding cutting edge. As Plutarch said – “The mind is a fire to be kindled , not a vessel to be filled.” . So far , I’ve never been cold.
Updated on July 08, 2022Comments
-
kanso almost 2 years
Is there a Java package with all the annoying time constants like milliseconds/seconds/minutes in a minute/hour/day/year? I'd hate to duplicate something like that.
-
kanso about 14 yearsduffymo: You're right , of course , but for our needs , 60 seconds in a minute is a good enough approximation
-
Basil Bourque almost 10 yearsSee the
DateTimeConstants
class in Joda-Time as well. -
M. Atif Riaz about 8 yearsTotally agree with your solution to avoid unnecessary dependency on third party library
-
Basil Bourque over 7 years
-
Basil Bourque over 7 years
-
simpleuser over 6 yearsany comments on why someone might prefer Duration over TimeUnit?
-
Yoory N. over 6 years
Duration.ofDays(1).getSeconds()
will create and throw away an object to do its work, comparing toTimeUnit.DAYS.toSeconds(1)
that only performs calculations. -
theadam over 5 yearsI think there is absolutely no reason to use Duration if all you need them to do is convert to a value. It is preferable to use Duration though in your API if that's what you need, in some cases this will be more readable then specifying value and unit as 2 separate arguments. I will remember to update my answer sometimes soon to indicate that.
-
Kong about 5 yearsAnother bonus of this solution is that it works if you need constants rather than method calls, such as when using them in annotations.
-
Vassilis about 3 yearsThe drawback is that you cannot use them in annotations, as they have to be compile time constants
-
walv about 3 yearsexactly what I was looking for, thank you
-
zypA13510 almost 3 yearsWhat about readability? I, for one, think
ofDays(1)
is clearer thantoSeconds(1)
in its meaning - I cannot imagine anyone to mistake 1 as the number of seconds when I doofDays(1)
, but I can imagine that happening fortoSeconds(1)
.