java sql time stamp in UTC 0 date part coming wrong
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box;
}
I am using following code for getting current system time which needed to be passed to some sql queries
java.util.Date date = new java.util.Date();
long t = date.getTime();
java.sql.Timestamp sqlTimestamp = new java.sql.Timestamp(t);
log.info("Current Time:" + sqlTimestamp.toString());
Now i also needed to get UTC 0 time (not GMT 0)
log.info("Current Time:" + sqlTimestamp.toString());
Current Time:2019-01-04 15:04:50.735
I am trying following code but it looks like not getting date part correctly
log.info("Current UTC Time:" + new java.sql.Timestamp(Instant.now().atOffset( ZoneOffset.UTC ).toEpochSecond()).toString());
Current UTC Time:1970-01-19 02:36:36.299
Please let me know what correction i needed
java java-8
add a comment |
I am using following code for getting current system time which needed to be passed to some sql queries
java.util.Date date = new java.util.Date();
long t = date.getTime();
java.sql.Timestamp sqlTimestamp = new java.sql.Timestamp(t);
log.info("Current Time:" + sqlTimestamp.toString());
Now i also needed to get UTC 0 time (not GMT 0)
log.info("Current Time:" + sqlTimestamp.toString());
Current Time:2019-01-04 15:04:50.735
I am trying following code but it looks like not getting date part correctly
log.info("Current UTC Time:" + new java.sql.Timestamp(Instant.now().atOffset( ZoneOffset.UTC ).toEpochSecond()).toString());
Current UTC Time:1970-01-19 02:36:36.299
Please let me know what correction i needed
java java-8
add a comment |
I am using following code for getting current system time which needed to be passed to some sql queries
java.util.Date date = new java.util.Date();
long t = date.getTime();
java.sql.Timestamp sqlTimestamp = new java.sql.Timestamp(t);
log.info("Current Time:" + sqlTimestamp.toString());
Now i also needed to get UTC 0 time (not GMT 0)
log.info("Current Time:" + sqlTimestamp.toString());
Current Time:2019-01-04 15:04:50.735
I am trying following code but it looks like not getting date part correctly
log.info("Current UTC Time:" + new java.sql.Timestamp(Instant.now().atOffset( ZoneOffset.UTC ).toEpochSecond()).toString());
Current UTC Time:1970-01-19 02:36:36.299
Please let me know what correction i needed
java java-8
I am using following code for getting current system time which needed to be passed to some sql queries
java.util.Date date = new java.util.Date();
long t = date.getTime();
java.sql.Timestamp sqlTimestamp = new java.sql.Timestamp(t);
log.info("Current Time:" + sqlTimestamp.toString());
Now i also needed to get UTC 0 time (not GMT 0)
log.info("Current Time:" + sqlTimestamp.toString());
Current Time:2019-01-04 15:04:50.735
I am trying following code but it looks like not getting date part correctly
log.info("Current UTC Time:" + new java.sql.Timestamp(Instant.now().atOffset( ZoneOffset.UTC ).toEpochSecond()).toString());
Current UTC Time:1970-01-19 02:36:36.299
Please let me know what correction i needed
java java-8
java java-8
asked Jan 4 at 10:12
Kamran ShahidKamran Shahid
1,67322546
1,67322546
add a comment |
add a comment |
4 Answers
4
active
oldest
votes
Why can't you use DateTimeFormatter
sqlTimestamp.toInstant().atOffset(ZoneOffset.UTC).format(DateTimeFormatter.ofPattern("uuuu-MM-dd HH:mm:ss.SSS"))
May as well simply useZonedDateTime.now(ZoneOffset.UTC)
instead of thesqlTimestamp.toInstant...
part. Anyway, your pattern is incorrect and should be"uuuu-MM-dd HH:mm:ss.SSSZ"
.
– TiiJ7
Jan 4 at 11:02
ok sir, i done the edit on the format
– Santhosh Arun
Jan 4 at 11:04
TiiJ7 i will try it as well. Thanks
– Kamran Shahid
Jan 4 at 21:13
add a comment |
tl;dr
Use the modern java.time classes instead.
Instant
.now()
.toString()
2019-01-23T01:23:45.123456789Z
java.time
You are using terrible old date-time classes that were supplanted years ago entirely by the java.time classes.
Capture the current moment.
Instant instant = Instant.now() ;
Generate text to represent that moment in standard ISO 8601 format.
String output = instant.toString() ;
If the T
in the middle bothers you, replace it. But I encourage you to stick with the strict ISO 8601 format for logging.
String outputModified = output.replace( "T" , " " ) ;
get UTC 0 time (not GMT 0)
UTC is the same thing as GMT, practically speaking, for common business-oriented apps.
both lines giving same time log.info("Current Time:" + sqlTimestamp.toString()); log.info("Current UTC Time:" + new java.sql.Timestamp(Instant.now().toEpochMilli()).toString());
– Kamran Shahid
Jan 4 at 10:36
As per your suggestion I can do "T" replacement and Z replacement but wanted to know if there is some built in api exists in java. I am mainly a .net developer but doing some correction in some legacy java code
– Kamran Shahid
Jan 4 at 10:42
1
@KamranShahid No, no, stop usingTimestamp
andDate
at all. Never touch those classes again. They are have many problems and bloody awful design. Forget about them, andCalendar
&SimpleDateFormat
. Use only classes from the java.time packages. To interoperable with old code not yet updated to java.time, use the new conversion methods added to the old classes.
– Basil Bourque
Jan 4 at 10:47
1
You should always keep theZ
as it indicates UTC. Without an indicator of offset-from-UTC or time zone, the text loses its meaning. For example, a twelve o’clock value could mean noon in Tokyo, noon in Kolkata, noon in Casablanca, or noon in Montréal, all very different moments. But if you insist, convert to anOffsetDateTime
and use aDateTimeFormatter
to suppress the display of the offset. But this would be a poor practice.
– Basil Bourque
Jan 4 at 10:53
1
@KamranShahid Tip: for .Net, check out the port of java.time predecessor Joda-Time in the Noda Time project.
– Basil Bourque
Jan 4 at 10:55
|
show 1 more comment
You are using toEpochSecond()
instead toEpochMilli()
Javadoc for your Timestamp
constructor
Timestamp(long time) Constructs a Timestamp object using a milliseconds time value.
So you can use Instant.now().toEpochMilli()
as Instant.now()
will return you Instant
in UTC
(And of course, avoid using old date API if possible, use new date API from JDK8)
Instant.now().atOffset( ZoneOffset.UTC ).toEpochSecond()
toInstant.now().atOffset( ZoneOffset.UTC ).toEpochMilli()
– ByeBye
Jan 4 at 10:29
log.info("Current UTC Time:" + new java.sql.Timestamp(Instant.now().atOffset(ZoneOffset.UTC ).toEpochMilli()).toString()); not compiling
– Kamran Shahid
Jan 4 at 10:31
Sorry -Instant.now().toEpochMilli()
– ByeBye
Jan 4 at 10:54
add a comment |
First avoid the classes Date
and Timestamp
. Instead of Timestamp
pass a modern type from java.time to your SQL query. Depending on the details of your JDBC driver and the requirements of your query use either Instant
, OffsetDateTime
with an offset of UTC (zero) or LocalDateTime
.
The Date
and Timestamp
classes have design issues and are long outdated. The Timestamp
class can be very confusing, and there doesn’t seem to be agreement whether to interpret it as a timestamp (as the name says) or as a date and time of day. Fortunately since JDBC 4.2 you don’t need Timestamp
anymore.
For example:
OffsetDateTime currentUtcTime = OffsetDateTime.now(ZoneOffset.UTC);
PreparedStatement ps = con.prepareStatement(
"select col1 from your_table where your_timestamp > ?;");
ps.setObject(1, currentUtcTime);
ResultSet rs = ps.executeQuery();
add a comment |
Your Answer
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: "1"
};
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: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
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%2fstackoverflow.com%2fquestions%2f54036858%2fjava-sql-time-stamp-in-utc-0-date-part-coming-wrong%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
Why can't you use DateTimeFormatter
sqlTimestamp.toInstant().atOffset(ZoneOffset.UTC).format(DateTimeFormatter.ofPattern("uuuu-MM-dd HH:mm:ss.SSS"))
May as well simply useZonedDateTime.now(ZoneOffset.UTC)
instead of thesqlTimestamp.toInstant...
part. Anyway, your pattern is incorrect and should be"uuuu-MM-dd HH:mm:ss.SSSZ"
.
– TiiJ7
Jan 4 at 11:02
ok sir, i done the edit on the format
– Santhosh Arun
Jan 4 at 11:04
TiiJ7 i will try it as well. Thanks
– Kamran Shahid
Jan 4 at 21:13
add a comment |
Why can't you use DateTimeFormatter
sqlTimestamp.toInstant().atOffset(ZoneOffset.UTC).format(DateTimeFormatter.ofPattern("uuuu-MM-dd HH:mm:ss.SSS"))
May as well simply useZonedDateTime.now(ZoneOffset.UTC)
instead of thesqlTimestamp.toInstant...
part. Anyway, your pattern is incorrect and should be"uuuu-MM-dd HH:mm:ss.SSSZ"
.
– TiiJ7
Jan 4 at 11:02
ok sir, i done the edit on the format
– Santhosh Arun
Jan 4 at 11:04
TiiJ7 i will try it as well. Thanks
– Kamran Shahid
Jan 4 at 21:13
add a comment |
Why can't you use DateTimeFormatter
sqlTimestamp.toInstant().atOffset(ZoneOffset.UTC).format(DateTimeFormatter.ofPattern("uuuu-MM-dd HH:mm:ss.SSS"))
Why can't you use DateTimeFormatter
sqlTimestamp.toInstant().atOffset(ZoneOffset.UTC).format(DateTimeFormatter.ofPattern("uuuu-MM-dd HH:mm:ss.SSS"))
edited Jan 4 at 11:04
answered Jan 4 at 10:53
Santhosh ArunSanthosh Arun
11017
11017
May as well simply useZonedDateTime.now(ZoneOffset.UTC)
instead of thesqlTimestamp.toInstant...
part. Anyway, your pattern is incorrect and should be"uuuu-MM-dd HH:mm:ss.SSSZ"
.
– TiiJ7
Jan 4 at 11:02
ok sir, i done the edit on the format
– Santhosh Arun
Jan 4 at 11:04
TiiJ7 i will try it as well. Thanks
– Kamran Shahid
Jan 4 at 21:13
add a comment |
May as well simply useZonedDateTime.now(ZoneOffset.UTC)
instead of thesqlTimestamp.toInstant...
part. Anyway, your pattern is incorrect and should be"uuuu-MM-dd HH:mm:ss.SSSZ"
.
– TiiJ7
Jan 4 at 11:02
ok sir, i done the edit on the format
– Santhosh Arun
Jan 4 at 11:04
TiiJ7 i will try it as well. Thanks
– Kamran Shahid
Jan 4 at 21:13
May as well simply use
ZonedDateTime.now(ZoneOffset.UTC)
instead of the sqlTimestamp.toInstant...
part. Anyway, your pattern is incorrect and should be "uuuu-MM-dd HH:mm:ss.SSSZ"
.– TiiJ7
Jan 4 at 11:02
May as well simply use
ZonedDateTime.now(ZoneOffset.UTC)
instead of the sqlTimestamp.toInstant...
part. Anyway, your pattern is incorrect and should be "uuuu-MM-dd HH:mm:ss.SSSZ"
.– TiiJ7
Jan 4 at 11:02
ok sir, i done the edit on the format
– Santhosh Arun
Jan 4 at 11:04
ok sir, i done the edit on the format
– Santhosh Arun
Jan 4 at 11:04
TiiJ7 i will try it as well. Thanks
– Kamran Shahid
Jan 4 at 21:13
TiiJ7 i will try it as well. Thanks
– Kamran Shahid
Jan 4 at 21:13
add a comment |
tl;dr
Use the modern java.time classes instead.
Instant
.now()
.toString()
2019-01-23T01:23:45.123456789Z
java.time
You are using terrible old date-time classes that were supplanted years ago entirely by the java.time classes.
Capture the current moment.
Instant instant = Instant.now() ;
Generate text to represent that moment in standard ISO 8601 format.
String output = instant.toString() ;
If the T
in the middle bothers you, replace it. But I encourage you to stick with the strict ISO 8601 format for logging.
String outputModified = output.replace( "T" , " " ) ;
get UTC 0 time (not GMT 0)
UTC is the same thing as GMT, practically speaking, for common business-oriented apps.
both lines giving same time log.info("Current Time:" + sqlTimestamp.toString()); log.info("Current UTC Time:" + new java.sql.Timestamp(Instant.now().toEpochMilli()).toString());
– Kamran Shahid
Jan 4 at 10:36
As per your suggestion I can do "T" replacement and Z replacement but wanted to know if there is some built in api exists in java. I am mainly a .net developer but doing some correction in some legacy java code
– Kamran Shahid
Jan 4 at 10:42
1
@KamranShahid No, no, stop usingTimestamp
andDate
at all. Never touch those classes again. They are have many problems and bloody awful design. Forget about them, andCalendar
&SimpleDateFormat
. Use only classes from the java.time packages. To interoperable with old code not yet updated to java.time, use the new conversion methods added to the old classes.
– Basil Bourque
Jan 4 at 10:47
1
You should always keep theZ
as it indicates UTC. Without an indicator of offset-from-UTC or time zone, the text loses its meaning. For example, a twelve o’clock value could mean noon in Tokyo, noon in Kolkata, noon in Casablanca, or noon in Montréal, all very different moments. But if you insist, convert to anOffsetDateTime
and use aDateTimeFormatter
to suppress the display of the offset. But this would be a poor practice.
– Basil Bourque
Jan 4 at 10:53
1
@KamranShahid Tip: for .Net, check out the port of java.time predecessor Joda-Time in the Noda Time project.
– Basil Bourque
Jan 4 at 10:55
|
show 1 more comment
tl;dr
Use the modern java.time classes instead.
Instant
.now()
.toString()
2019-01-23T01:23:45.123456789Z
java.time
You are using terrible old date-time classes that were supplanted years ago entirely by the java.time classes.
Capture the current moment.
Instant instant = Instant.now() ;
Generate text to represent that moment in standard ISO 8601 format.
String output = instant.toString() ;
If the T
in the middle bothers you, replace it. But I encourage you to stick with the strict ISO 8601 format for logging.
String outputModified = output.replace( "T" , " " ) ;
get UTC 0 time (not GMT 0)
UTC is the same thing as GMT, practically speaking, for common business-oriented apps.
both lines giving same time log.info("Current Time:" + sqlTimestamp.toString()); log.info("Current UTC Time:" + new java.sql.Timestamp(Instant.now().toEpochMilli()).toString());
– Kamran Shahid
Jan 4 at 10:36
As per your suggestion I can do "T" replacement and Z replacement but wanted to know if there is some built in api exists in java. I am mainly a .net developer but doing some correction in some legacy java code
– Kamran Shahid
Jan 4 at 10:42
1
@KamranShahid No, no, stop usingTimestamp
andDate
at all. Never touch those classes again. They are have many problems and bloody awful design. Forget about them, andCalendar
&SimpleDateFormat
. Use only classes from the java.time packages. To interoperable with old code not yet updated to java.time, use the new conversion methods added to the old classes.
– Basil Bourque
Jan 4 at 10:47
1
You should always keep theZ
as it indicates UTC. Without an indicator of offset-from-UTC or time zone, the text loses its meaning. For example, a twelve o’clock value could mean noon in Tokyo, noon in Kolkata, noon in Casablanca, or noon in Montréal, all very different moments. But if you insist, convert to anOffsetDateTime
and use aDateTimeFormatter
to suppress the display of the offset. But this would be a poor practice.
– Basil Bourque
Jan 4 at 10:53
1
@KamranShahid Tip: for .Net, check out the port of java.time predecessor Joda-Time in the Noda Time project.
– Basil Bourque
Jan 4 at 10:55
|
show 1 more comment
tl;dr
Use the modern java.time classes instead.
Instant
.now()
.toString()
2019-01-23T01:23:45.123456789Z
java.time
You are using terrible old date-time classes that were supplanted years ago entirely by the java.time classes.
Capture the current moment.
Instant instant = Instant.now() ;
Generate text to represent that moment in standard ISO 8601 format.
String output = instant.toString() ;
If the T
in the middle bothers you, replace it. But I encourage you to stick with the strict ISO 8601 format for logging.
String outputModified = output.replace( "T" , " " ) ;
get UTC 0 time (not GMT 0)
UTC is the same thing as GMT, practically speaking, for common business-oriented apps.
tl;dr
Use the modern java.time classes instead.
Instant
.now()
.toString()
2019-01-23T01:23:45.123456789Z
java.time
You are using terrible old date-time classes that were supplanted years ago entirely by the java.time classes.
Capture the current moment.
Instant instant = Instant.now() ;
Generate text to represent that moment in standard ISO 8601 format.
String output = instant.toString() ;
If the T
in the middle bothers you, replace it. But I encourage you to stick with the strict ISO 8601 format for logging.
String outputModified = output.replace( "T" , " " ) ;
get UTC 0 time (not GMT 0)
UTC is the same thing as GMT, practically speaking, for common business-oriented apps.
edited Jan 4 at 10:56
answered Jan 4 at 10:28
Basil BourqueBasil Bourque
118k31399564
118k31399564
both lines giving same time log.info("Current Time:" + sqlTimestamp.toString()); log.info("Current UTC Time:" + new java.sql.Timestamp(Instant.now().toEpochMilli()).toString());
– Kamran Shahid
Jan 4 at 10:36
As per your suggestion I can do "T" replacement and Z replacement but wanted to know if there is some built in api exists in java. I am mainly a .net developer but doing some correction in some legacy java code
– Kamran Shahid
Jan 4 at 10:42
1
@KamranShahid No, no, stop usingTimestamp
andDate
at all. Never touch those classes again. They are have many problems and bloody awful design. Forget about them, andCalendar
&SimpleDateFormat
. Use only classes from the java.time packages. To interoperable with old code not yet updated to java.time, use the new conversion methods added to the old classes.
– Basil Bourque
Jan 4 at 10:47
1
You should always keep theZ
as it indicates UTC. Without an indicator of offset-from-UTC or time zone, the text loses its meaning. For example, a twelve o’clock value could mean noon in Tokyo, noon in Kolkata, noon in Casablanca, or noon in Montréal, all very different moments. But if you insist, convert to anOffsetDateTime
and use aDateTimeFormatter
to suppress the display of the offset. But this would be a poor practice.
– Basil Bourque
Jan 4 at 10:53
1
@KamranShahid Tip: for .Net, check out the port of java.time predecessor Joda-Time in the Noda Time project.
– Basil Bourque
Jan 4 at 10:55
|
show 1 more comment
both lines giving same time log.info("Current Time:" + sqlTimestamp.toString()); log.info("Current UTC Time:" + new java.sql.Timestamp(Instant.now().toEpochMilli()).toString());
– Kamran Shahid
Jan 4 at 10:36
As per your suggestion I can do "T" replacement and Z replacement but wanted to know if there is some built in api exists in java. I am mainly a .net developer but doing some correction in some legacy java code
– Kamran Shahid
Jan 4 at 10:42
1
@KamranShahid No, no, stop usingTimestamp
andDate
at all. Never touch those classes again. They are have many problems and bloody awful design. Forget about them, andCalendar
&SimpleDateFormat
. Use only classes from the java.time packages. To interoperable with old code not yet updated to java.time, use the new conversion methods added to the old classes.
– Basil Bourque
Jan 4 at 10:47
1
You should always keep theZ
as it indicates UTC. Without an indicator of offset-from-UTC or time zone, the text loses its meaning. For example, a twelve o’clock value could mean noon in Tokyo, noon in Kolkata, noon in Casablanca, or noon in Montréal, all very different moments. But if you insist, convert to anOffsetDateTime
and use aDateTimeFormatter
to suppress the display of the offset. But this would be a poor practice.
– Basil Bourque
Jan 4 at 10:53
1
@KamranShahid Tip: for .Net, check out the port of java.time predecessor Joda-Time in the Noda Time project.
– Basil Bourque
Jan 4 at 10:55
both lines giving same time log.info("Current Time:" + sqlTimestamp.toString()); log.info("Current UTC Time:" + new java.sql.Timestamp(Instant.now().toEpochMilli()).toString());
– Kamran Shahid
Jan 4 at 10:36
both lines giving same time log.info("Current Time:" + sqlTimestamp.toString()); log.info("Current UTC Time:" + new java.sql.Timestamp(Instant.now().toEpochMilli()).toString());
– Kamran Shahid
Jan 4 at 10:36
As per your suggestion I can do "T" replacement and Z replacement but wanted to know if there is some built in api exists in java. I am mainly a .net developer but doing some correction in some legacy java code
– Kamran Shahid
Jan 4 at 10:42
As per your suggestion I can do "T" replacement and Z replacement but wanted to know if there is some built in api exists in java. I am mainly a .net developer but doing some correction in some legacy java code
– Kamran Shahid
Jan 4 at 10:42
1
1
@KamranShahid No, no, stop using
Timestamp
and Date
at all. Never touch those classes again. They are have many problems and bloody awful design. Forget about them, and Calendar
& SimpleDateFormat
. Use only classes from the java.time packages. To interoperable with old code not yet updated to java.time, use the new conversion methods added to the old classes.– Basil Bourque
Jan 4 at 10:47
@KamranShahid No, no, stop using
Timestamp
and Date
at all. Never touch those classes again. They are have many problems and bloody awful design. Forget about them, and Calendar
& SimpleDateFormat
. Use only classes from the java.time packages. To interoperable with old code not yet updated to java.time, use the new conversion methods added to the old classes.– Basil Bourque
Jan 4 at 10:47
1
1
You should always keep the
Z
as it indicates UTC. Without an indicator of offset-from-UTC or time zone, the text loses its meaning. For example, a twelve o’clock value could mean noon in Tokyo, noon in Kolkata, noon in Casablanca, or noon in Montréal, all very different moments. But if you insist, convert to an OffsetDateTime
and use a DateTimeFormatter
to suppress the display of the offset. But this would be a poor practice.– Basil Bourque
Jan 4 at 10:53
You should always keep the
Z
as it indicates UTC. Without an indicator of offset-from-UTC or time zone, the text loses its meaning. For example, a twelve o’clock value could mean noon in Tokyo, noon in Kolkata, noon in Casablanca, or noon in Montréal, all very different moments. But if you insist, convert to an OffsetDateTime
and use a DateTimeFormatter
to suppress the display of the offset. But this would be a poor practice.– Basil Bourque
Jan 4 at 10:53
1
1
@KamranShahid Tip: for .Net, check out the port of java.time predecessor Joda-Time in the Noda Time project.
– Basil Bourque
Jan 4 at 10:55
@KamranShahid Tip: for .Net, check out the port of java.time predecessor Joda-Time in the Noda Time project.
– Basil Bourque
Jan 4 at 10:55
|
show 1 more comment
You are using toEpochSecond()
instead toEpochMilli()
Javadoc for your Timestamp
constructor
Timestamp(long time) Constructs a Timestamp object using a milliseconds time value.
So you can use Instant.now().toEpochMilli()
as Instant.now()
will return you Instant
in UTC
(And of course, avoid using old date API if possible, use new date API from JDK8)
Instant.now().atOffset( ZoneOffset.UTC ).toEpochSecond()
toInstant.now().atOffset( ZoneOffset.UTC ).toEpochMilli()
– ByeBye
Jan 4 at 10:29
log.info("Current UTC Time:" + new java.sql.Timestamp(Instant.now().atOffset(ZoneOffset.UTC ).toEpochMilli()).toString()); not compiling
– Kamran Shahid
Jan 4 at 10:31
Sorry -Instant.now().toEpochMilli()
– ByeBye
Jan 4 at 10:54
add a comment |
You are using toEpochSecond()
instead toEpochMilli()
Javadoc for your Timestamp
constructor
Timestamp(long time) Constructs a Timestamp object using a milliseconds time value.
So you can use Instant.now().toEpochMilli()
as Instant.now()
will return you Instant
in UTC
(And of course, avoid using old date API if possible, use new date API from JDK8)
Instant.now().atOffset( ZoneOffset.UTC ).toEpochSecond()
toInstant.now().atOffset( ZoneOffset.UTC ).toEpochMilli()
– ByeBye
Jan 4 at 10:29
log.info("Current UTC Time:" + new java.sql.Timestamp(Instant.now().atOffset(ZoneOffset.UTC ).toEpochMilli()).toString()); not compiling
– Kamran Shahid
Jan 4 at 10:31
Sorry -Instant.now().toEpochMilli()
– ByeBye
Jan 4 at 10:54
add a comment |
You are using toEpochSecond()
instead toEpochMilli()
Javadoc for your Timestamp
constructor
Timestamp(long time) Constructs a Timestamp object using a milliseconds time value.
So you can use Instant.now().toEpochMilli()
as Instant.now()
will return you Instant
in UTC
(And of course, avoid using old date API if possible, use new date API from JDK8)
You are using toEpochSecond()
instead toEpochMilli()
Javadoc for your Timestamp
constructor
Timestamp(long time) Constructs a Timestamp object using a milliseconds time value.
So you can use Instant.now().toEpochMilli()
as Instant.now()
will return you Instant
in UTC
(And of course, avoid using old date API if possible, use new date API from JDK8)
edited Jan 4 at 11:04
answered Jan 4 at 10:17
ByeByeByeBye
3,85831041
3,85831041
Instant.now().atOffset( ZoneOffset.UTC ).toEpochSecond()
toInstant.now().atOffset( ZoneOffset.UTC ).toEpochMilli()
– ByeBye
Jan 4 at 10:29
log.info("Current UTC Time:" + new java.sql.Timestamp(Instant.now().atOffset(ZoneOffset.UTC ).toEpochMilli()).toString()); not compiling
– Kamran Shahid
Jan 4 at 10:31
Sorry -Instant.now().toEpochMilli()
– ByeBye
Jan 4 at 10:54
add a comment |
Instant.now().atOffset( ZoneOffset.UTC ).toEpochSecond()
toInstant.now().atOffset( ZoneOffset.UTC ).toEpochMilli()
– ByeBye
Jan 4 at 10:29
log.info("Current UTC Time:" + new java.sql.Timestamp(Instant.now().atOffset(ZoneOffset.UTC ).toEpochMilli()).toString()); not compiling
– Kamran Shahid
Jan 4 at 10:31
Sorry -Instant.now().toEpochMilli()
– ByeBye
Jan 4 at 10:54
Instant.now().atOffset( ZoneOffset.UTC ).toEpochSecond()
to Instant.now().atOffset( ZoneOffset.UTC ).toEpochMilli()
– ByeBye
Jan 4 at 10:29
Instant.now().atOffset( ZoneOffset.UTC ).toEpochSecond()
to Instant.now().atOffset( ZoneOffset.UTC ).toEpochMilli()
– ByeBye
Jan 4 at 10:29
log.info("Current UTC Time:" + new java.sql.Timestamp(Instant.now().atOffset(ZoneOffset.UTC ).toEpochMilli()).toString()); not compiling
– Kamran Shahid
Jan 4 at 10:31
log.info("Current UTC Time:" + new java.sql.Timestamp(Instant.now().atOffset(ZoneOffset.UTC ).toEpochMilli()).toString()); not compiling
– Kamran Shahid
Jan 4 at 10:31
Sorry -
Instant.now().toEpochMilli()
– ByeBye
Jan 4 at 10:54
Sorry -
Instant.now().toEpochMilli()
– ByeBye
Jan 4 at 10:54
add a comment |
First avoid the classes Date
and Timestamp
. Instead of Timestamp
pass a modern type from java.time to your SQL query. Depending on the details of your JDBC driver and the requirements of your query use either Instant
, OffsetDateTime
with an offset of UTC (zero) or LocalDateTime
.
The Date
and Timestamp
classes have design issues and are long outdated. The Timestamp
class can be very confusing, and there doesn’t seem to be agreement whether to interpret it as a timestamp (as the name says) or as a date and time of day. Fortunately since JDBC 4.2 you don’t need Timestamp
anymore.
For example:
OffsetDateTime currentUtcTime = OffsetDateTime.now(ZoneOffset.UTC);
PreparedStatement ps = con.prepareStatement(
"select col1 from your_table where your_timestamp > ?;");
ps.setObject(1, currentUtcTime);
ResultSet rs = ps.executeQuery();
add a comment |
First avoid the classes Date
and Timestamp
. Instead of Timestamp
pass a modern type from java.time to your SQL query. Depending on the details of your JDBC driver and the requirements of your query use either Instant
, OffsetDateTime
with an offset of UTC (zero) or LocalDateTime
.
The Date
and Timestamp
classes have design issues and are long outdated. The Timestamp
class can be very confusing, and there doesn’t seem to be agreement whether to interpret it as a timestamp (as the name says) or as a date and time of day. Fortunately since JDBC 4.2 you don’t need Timestamp
anymore.
For example:
OffsetDateTime currentUtcTime = OffsetDateTime.now(ZoneOffset.UTC);
PreparedStatement ps = con.prepareStatement(
"select col1 from your_table where your_timestamp > ?;");
ps.setObject(1, currentUtcTime);
ResultSet rs = ps.executeQuery();
add a comment |
First avoid the classes Date
and Timestamp
. Instead of Timestamp
pass a modern type from java.time to your SQL query. Depending on the details of your JDBC driver and the requirements of your query use either Instant
, OffsetDateTime
with an offset of UTC (zero) or LocalDateTime
.
The Date
and Timestamp
classes have design issues and are long outdated. The Timestamp
class can be very confusing, and there doesn’t seem to be agreement whether to interpret it as a timestamp (as the name says) or as a date and time of day. Fortunately since JDBC 4.2 you don’t need Timestamp
anymore.
For example:
OffsetDateTime currentUtcTime = OffsetDateTime.now(ZoneOffset.UTC);
PreparedStatement ps = con.prepareStatement(
"select col1 from your_table where your_timestamp > ?;");
ps.setObject(1, currentUtcTime);
ResultSet rs = ps.executeQuery();
First avoid the classes Date
and Timestamp
. Instead of Timestamp
pass a modern type from java.time to your SQL query. Depending on the details of your JDBC driver and the requirements of your query use either Instant
, OffsetDateTime
with an offset of UTC (zero) or LocalDateTime
.
The Date
and Timestamp
classes have design issues and are long outdated. The Timestamp
class can be very confusing, and there doesn’t seem to be agreement whether to interpret it as a timestamp (as the name says) or as a date and time of day. Fortunately since JDBC 4.2 you don’t need Timestamp
anymore.
For example:
OffsetDateTime currentUtcTime = OffsetDateTime.now(ZoneOffset.UTC);
PreparedStatement ps = con.prepareStatement(
"select col1 from your_table where your_timestamp > ?;");
ps.setObject(1, currentUtcTime);
ResultSet rs = ps.executeQuery();
answered Jan 4 at 10:52
Ole V.V.Ole V.V.
32.9k74259
32.9k74259
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- 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.
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%2fstackoverflow.com%2fquestions%2f54036858%2fjava-sql-time-stamp-in-utc-0-date-part-coming-wrong%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