Getting the current timestamp and compute the timestamp difference in minutes
$begingroup$
I have this code to get the current Timestamp and compute the last timestamp's difference with the current timestamp in minutes. I'm wondering if this can be optimized further for production.
public static Timestamp getTimestamp() {
java.util.Date date= new java.util.Date();
long time = date.getTime();
java.sql.Timestamp ts = new java.sql.Timestamp(time);
return ts;
}
public static long getLastTimestampElapse(java.sql.Timestamp oldTime){
long milliseconds1 = oldTime.getTime();
long milliseconds2 = getTimestamp().getTime();
long diff = milliseconds2 - milliseconds1;
long diffMinutes = diff / (60 * 1000);
return diffMinutes;
}
java performance datetime
$endgroup$
add a comment |
$begingroup$
I have this code to get the current Timestamp and compute the last timestamp's difference with the current timestamp in minutes. I'm wondering if this can be optimized further for production.
public static Timestamp getTimestamp() {
java.util.Date date= new java.util.Date();
long time = date.getTime();
java.sql.Timestamp ts = new java.sql.Timestamp(time);
return ts;
}
public static long getLastTimestampElapse(java.sql.Timestamp oldTime){
long milliseconds1 = oldTime.getTime();
long milliseconds2 = getTimestamp().getTime();
long diff = milliseconds2 - milliseconds1;
long diffMinutes = diff / (60 * 1000);
return diffMinutes;
}
java performance datetime
$endgroup$
add a comment |
$begingroup$
I have this code to get the current Timestamp and compute the last timestamp's difference with the current timestamp in minutes. I'm wondering if this can be optimized further for production.
public static Timestamp getTimestamp() {
java.util.Date date= new java.util.Date();
long time = date.getTime();
java.sql.Timestamp ts = new java.sql.Timestamp(time);
return ts;
}
public static long getLastTimestampElapse(java.sql.Timestamp oldTime){
long milliseconds1 = oldTime.getTime();
long milliseconds2 = getTimestamp().getTime();
long diff = milliseconds2 - milliseconds1;
long diffMinutes = diff / (60 * 1000);
return diffMinutes;
}
java performance datetime
$endgroup$
I have this code to get the current Timestamp and compute the last timestamp's difference with the current timestamp in minutes. I'm wondering if this can be optimized further for production.
public static Timestamp getTimestamp() {
java.util.Date date= new java.util.Date();
long time = date.getTime();
java.sql.Timestamp ts = new java.sql.Timestamp(time);
return ts;
}
public static long getLastTimestampElapse(java.sql.Timestamp oldTime){
long milliseconds1 = oldTime.getTime();
long milliseconds2 = getTimestamp().getTime();
long diff = milliseconds2 - milliseconds1;
long diffMinutes = diff / (60 * 1000);
return diffMinutes;
}
java performance datetime
java performance datetime
edited 8 mins ago
Jamal♦
30.4k11121227
30.4k11121227
asked yesterday
RanPaulRanPaul
3902513
3902513
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
$begingroup$
Note that none of these suggestions will have any significant impact on the performance of your application overall. Don't micro-optimize performance until you have known, tested bottlenecks.
The getTimestamp()
method is noise. If all you care about is the current timestamp in milliseconds, use System.currentTimeMillis()
.
You can use a constant to store the number of milliseconds in a minute, potentially saving the multiplication. Even if the compiler optimizes the math away, it's easier to read.
A java.sql.Timestamp
is a kind of java.util.Date
, and the getTime()
method is defined there. Your method should accept a java.util.Date
to support more clients at no cost.
Your method is poorly named. Something like getMinutesSince()
would be more readable. Likewise, there are better variable names than what you've selected.
Use final
to indicate that variables won't be reassigned. That reduces the cognitive load on the reader.
You don't really need as many variables as you have. You might even be able to get away with none and still have a reasonably clear method.
If you were to use all my suggestions, your code might look more like:
private static final long MILLISECONDS_PER_MINUTE = 60 * 1000;
public static long getMinutesSince(final java.util.Date startTime) {
final long millisecondsSinceStart =
System.currentTimeMillis() - startTime.getTime();
return millisecondsSinceStart / MILLISECONDS_PER_MINUTE;
}
$endgroup$
1
$begingroup$
You might want to assignMILLISECONDS_PER_MINUTE
to something. :-)
$endgroup$
– AJNeufeld
yesterday
1
$begingroup$
TimeUnit.MILLISECONDS.toMinutes(millisecondsSinceStart) - TimeUnit already has constants for you
$endgroup$
– Alexey Ragozin
23 hours ago
$begingroup$
@AJNeufeld That's what I get for editing directly in the window instead of moving to my editor. Fixed, thanks!
$endgroup$
– Eric Stein
13 hours ago
$begingroup$
@AlexeyRagozin That's a good point. I personally find it harder to read in this case, but it's a good option for the OP to be aware of. Thanks!
$endgroup$
– Eric Stein
13 hours ago
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
return StackExchange.using("mathjaxEditing", function () {
StackExchange.MarkdownEditor.creationCallbacks.add(function (editor, postfix) {
StackExchange.mathjaxEditing.prepareWmdForMathJax(editor, postfix, [["\$", "\$"]]);
});
});
}, "mathjax-editing");
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "196"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcodereview.stackexchange.com%2fquestions%2f215432%2fgetting-the-current-timestamp-and-compute-the-timestamp-difference-in-minutes%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
$begingroup$
Note that none of these suggestions will have any significant impact on the performance of your application overall. Don't micro-optimize performance until you have known, tested bottlenecks.
The getTimestamp()
method is noise. If all you care about is the current timestamp in milliseconds, use System.currentTimeMillis()
.
You can use a constant to store the number of milliseconds in a minute, potentially saving the multiplication. Even if the compiler optimizes the math away, it's easier to read.
A java.sql.Timestamp
is a kind of java.util.Date
, and the getTime()
method is defined there. Your method should accept a java.util.Date
to support more clients at no cost.
Your method is poorly named. Something like getMinutesSince()
would be more readable. Likewise, there are better variable names than what you've selected.
Use final
to indicate that variables won't be reassigned. That reduces the cognitive load on the reader.
You don't really need as many variables as you have. You might even be able to get away with none and still have a reasonably clear method.
If you were to use all my suggestions, your code might look more like:
private static final long MILLISECONDS_PER_MINUTE = 60 * 1000;
public static long getMinutesSince(final java.util.Date startTime) {
final long millisecondsSinceStart =
System.currentTimeMillis() - startTime.getTime();
return millisecondsSinceStart / MILLISECONDS_PER_MINUTE;
}
$endgroup$
1
$begingroup$
You might want to assignMILLISECONDS_PER_MINUTE
to something. :-)
$endgroup$
– AJNeufeld
yesterday
1
$begingroup$
TimeUnit.MILLISECONDS.toMinutes(millisecondsSinceStart) - TimeUnit already has constants for you
$endgroup$
– Alexey Ragozin
23 hours ago
$begingroup$
@AJNeufeld That's what I get for editing directly in the window instead of moving to my editor. Fixed, thanks!
$endgroup$
– Eric Stein
13 hours ago
$begingroup$
@AlexeyRagozin That's a good point. I personally find it harder to read in this case, but it's a good option for the OP to be aware of. Thanks!
$endgroup$
– Eric Stein
13 hours ago
add a comment |
$begingroup$
Note that none of these suggestions will have any significant impact on the performance of your application overall. Don't micro-optimize performance until you have known, tested bottlenecks.
The getTimestamp()
method is noise. If all you care about is the current timestamp in milliseconds, use System.currentTimeMillis()
.
You can use a constant to store the number of milliseconds in a minute, potentially saving the multiplication. Even if the compiler optimizes the math away, it's easier to read.
A java.sql.Timestamp
is a kind of java.util.Date
, and the getTime()
method is defined there. Your method should accept a java.util.Date
to support more clients at no cost.
Your method is poorly named. Something like getMinutesSince()
would be more readable. Likewise, there are better variable names than what you've selected.
Use final
to indicate that variables won't be reassigned. That reduces the cognitive load on the reader.
You don't really need as many variables as you have. You might even be able to get away with none and still have a reasonably clear method.
If you were to use all my suggestions, your code might look more like:
private static final long MILLISECONDS_PER_MINUTE = 60 * 1000;
public static long getMinutesSince(final java.util.Date startTime) {
final long millisecondsSinceStart =
System.currentTimeMillis() - startTime.getTime();
return millisecondsSinceStart / MILLISECONDS_PER_MINUTE;
}
$endgroup$
1
$begingroup$
You might want to assignMILLISECONDS_PER_MINUTE
to something. :-)
$endgroup$
– AJNeufeld
yesterday
1
$begingroup$
TimeUnit.MILLISECONDS.toMinutes(millisecondsSinceStart) - TimeUnit already has constants for you
$endgroup$
– Alexey Ragozin
23 hours ago
$begingroup$
@AJNeufeld That's what I get for editing directly in the window instead of moving to my editor. Fixed, thanks!
$endgroup$
– Eric Stein
13 hours ago
$begingroup$
@AlexeyRagozin That's a good point. I personally find it harder to read in this case, but it's a good option for the OP to be aware of. Thanks!
$endgroup$
– Eric Stein
13 hours ago
add a comment |
$begingroup$
Note that none of these suggestions will have any significant impact on the performance of your application overall. Don't micro-optimize performance until you have known, tested bottlenecks.
The getTimestamp()
method is noise. If all you care about is the current timestamp in milliseconds, use System.currentTimeMillis()
.
You can use a constant to store the number of milliseconds in a minute, potentially saving the multiplication. Even if the compiler optimizes the math away, it's easier to read.
A java.sql.Timestamp
is a kind of java.util.Date
, and the getTime()
method is defined there. Your method should accept a java.util.Date
to support more clients at no cost.
Your method is poorly named. Something like getMinutesSince()
would be more readable. Likewise, there are better variable names than what you've selected.
Use final
to indicate that variables won't be reassigned. That reduces the cognitive load on the reader.
You don't really need as many variables as you have. You might even be able to get away with none and still have a reasonably clear method.
If you were to use all my suggestions, your code might look more like:
private static final long MILLISECONDS_PER_MINUTE = 60 * 1000;
public static long getMinutesSince(final java.util.Date startTime) {
final long millisecondsSinceStart =
System.currentTimeMillis() - startTime.getTime();
return millisecondsSinceStart / MILLISECONDS_PER_MINUTE;
}
$endgroup$
Note that none of these suggestions will have any significant impact on the performance of your application overall. Don't micro-optimize performance until you have known, tested bottlenecks.
The getTimestamp()
method is noise. If all you care about is the current timestamp in milliseconds, use System.currentTimeMillis()
.
You can use a constant to store the number of milliseconds in a minute, potentially saving the multiplication. Even if the compiler optimizes the math away, it's easier to read.
A java.sql.Timestamp
is a kind of java.util.Date
, and the getTime()
method is defined there. Your method should accept a java.util.Date
to support more clients at no cost.
Your method is poorly named. Something like getMinutesSince()
would be more readable. Likewise, there are better variable names than what you've selected.
Use final
to indicate that variables won't be reassigned. That reduces the cognitive load on the reader.
You don't really need as many variables as you have. You might even be able to get away with none and still have a reasonably clear method.
If you were to use all my suggestions, your code might look more like:
private static final long MILLISECONDS_PER_MINUTE = 60 * 1000;
public static long getMinutesSince(final java.util.Date startTime) {
final long millisecondsSinceStart =
System.currentTimeMillis() - startTime.getTime();
return millisecondsSinceStart / MILLISECONDS_PER_MINUTE;
}
edited 13 hours ago
answered yesterday
Eric SteinEric Stein
4,252613
4,252613
1
$begingroup$
You might want to assignMILLISECONDS_PER_MINUTE
to something. :-)
$endgroup$
– AJNeufeld
yesterday
1
$begingroup$
TimeUnit.MILLISECONDS.toMinutes(millisecondsSinceStart) - TimeUnit already has constants for you
$endgroup$
– Alexey Ragozin
23 hours ago
$begingroup$
@AJNeufeld That's what I get for editing directly in the window instead of moving to my editor. Fixed, thanks!
$endgroup$
– Eric Stein
13 hours ago
$begingroup$
@AlexeyRagozin That's a good point. I personally find it harder to read in this case, but it's a good option for the OP to be aware of. Thanks!
$endgroup$
– Eric Stein
13 hours ago
add a comment |
1
$begingroup$
You might want to assignMILLISECONDS_PER_MINUTE
to something. :-)
$endgroup$
– AJNeufeld
yesterday
1
$begingroup$
TimeUnit.MILLISECONDS.toMinutes(millisecondsSinceStart) - TimeUnit already has constants for you
$endgroup$
– Alexey Ragozin
23 hours ago
$begingroup$
@AJNeufeld That's what I get for editing directly in the window instead of moving to my editor. Fixed, thanks!
$endgroup$
– Eric Stein
13 hours ago
$begingroup$
@AlexeyRagozin That's a good point. I personally find it harder to read in this case, but it's a good option for the OP to be aware of. Thanks!
$endgroup$
– Eric Stein
13 hours ago
1
1
$begingroup$
You might want to assign
MILLISECONDS_PER_MINUTE
to something. :-)$endgroup$
– AJNeufeld
yesterday
$begingroup$
You might want to assign
MILLISECONDS_PER_MINUTE
to something. :-)$endgroup$
– AJNeufeld
yesterday
1
1
$begingroup$
TimeUnit.MILLISECONDS.toMinutes(millisecondsSinceStart) - TimeUnit already has constants for you
$endgroup$
– Alexey Ragozin
23 hours ago
$begingroup$
TimeUnit.MILLISECONDS.toMinutes(millisecondsSinceStart) - TimeUnit already has constants for you
$endgroup$
– Alexey Ragozin
23 hours ago
$begingroup$
@AJNeufeld That's what I get for editing directly in the window instead of moving to my editor. Fixed, thanks!
$endgroup$
– Eric Stein
13 hours ago
$begingroup$
@AJNeufeld That's what I get for editing directly in the window instead of moving to my editor. Fixed, thanks!
$endgroup$
– Eric Stein
13 hours ago
$begingroup$
@AlexeyRagozin That's a good point. I personally find it harder to read in this case, but it's a good option for the OP to be aware of. Thanks!
$endgroup$
– Eric Stein
13 hours ago
$begingroup$
@AlexeyRagozin That's a good point. I personally find it harder to read in this case, but it's a good option for the OP to be aware of. Thanks!
$endgroup$
– Eric Stein
13 hours ago
add a comment |
Thanks for contributing an answer to Code Review Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
Use MathJax to format equations. MathJax reference.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcodereview.stackexchange.com%2fquestions%2f215432%2fgetting-the-current-timestamp-and-compute-the-timestamp-difference-in-minutes%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown