Using Spring Boot 1.5.4.RELEASE and Mongo driver 3.4.2.
I want to store LocalDate in mongo DB, but I am facing a weird problem:
LocalDate startDate = LocalDate.now();
LocalDate endDate = LocalDate.of(2020,12,01);
System.out.println("---- StartDate : ---"+startDate);
System.out.println("-----End Date : ----"+endDate);
repository.save(new Person("Mehraj","Malik", startDate, endDate));
Output on console:
---- StartDate : ---2017-08-26
-----End Date : ----2020-12-01
But In MongoDb it is storing incorrect dates.
Following is the json from MongoDb:
"startDate" : ISODate("2017-08-25T18:30:00.000Z"),
"endDate" :ISODate("2020-11-30T18:30:00.000Z")
Also, I have noticed that the stored time is also incorrect according to Indian time.
Why the dates are correct on console but not in MongoDB and how to resolve this problem?
The mongo-java client for a date object returns as instance of
java.util.Date.
The problem could possibly be that while you save the startDate and the endDate value, its toString() method would probably use the JVM's default time zone to update the value.
The doc here states that The official BSON specification refers to the BSON Date type as the UTC datetime. and that could be the reason your LocalDateTime attributes were converted to the UTC time zone prior to being saved to the DB.
Also to avoid such confusion would suggest using the bson type timestamp to update date fields.
In the MongoDB Java Driver 3.7 release : http://mongodb.github.io/mongo-java-driver/3.7/whats-new/ we can see that the driver now support LocalDate :
JSR-310 Instant, LocalDate & LocalDateTime support
Support for Instant, LocalDate and LocalDateTime has been added to the driver.
I have to store UTC dateTime in DB.
I have converted the dateTime given in specific timezone to UTC. for that I followed the below code.
My input dateTime is "20121225 10:00:00 Z" timezone is "Asia/Calcutta"
My Server/DB(oracle) is running in the same timezone(IST) "Asia/Calcutta"
Get the Date object in this specific Timezone
String date = "20121225 10:00:00 Z";
String timeZoneId = "Asia/Calcutta";
TimeZone timeZone = TimeZone.getTimeZone(timeZoneId);
DateFormat dateFormatLocal = new SimpleDateFormat("yyyyMMdd HH:mm:ss z");
//This date object is given time and given timezone
java.util.Date parsedDate = dateFormatLocal.parse(date + " "
+ timeZone.getDisplayName(false, TimeZone.SHORT));
if (timeZone.inDaylightTime(parsedDate)) {
// We need to re-parse because we don't know if the date
// is DST until it is parsed...
parsedDate = dateFormatLocal.parse(date + " "
+ timeZone.getDisplayName(true, TimeZone.SHORT));
}
//assigning to the java.sql.TimeStamp instace variable
obj.setTsSchedStartTime(new java.sql.Timestamp(parsedDate.getTime()));
Store into DB
if (tsSchedStartTime != null) {
stmt.setTimestamp(11, tsSchedStartTime);
} else {
stmt.setNull(11, java.sql.Types.DATE);
}
OUTPUT
DB (oracle) has stored the same given dateTime: "20121225 10:00:00 not in UTC.
I have confirmed from the below sql.
select to_char(sched_start_time, 'yyyy/mm/dd hh24:mi:ss') from myTable
My DB server also running on the same timezone "Asia/Calcutta"
It gives me the below appearances
Date.getTime() is not in UTC
Or Timestamp is has timezone impact while storing into DB
What am I doing wrong here?
One more question:
Will timeStamp.toString() print in local timezone like java.util.date does? Not UTC?
Although it is not explicitly specified for setTimestamp(int parameterIndex, Timestamp x) drivers have to follow the rules established by the setTimestamp(int parameterIndex, Timestamp x, Calendar cal) javadoc:
Sets the designated parameter to the given java.sql.Timestamp value, using the given Calendar object. The driver uses the Calendar object to construct an SQL TIMESTAMP value, which the driver then sends to the database. With a Calendar object, the driver can calculate the timestamp taking into account a custom time zone. If no Calendar object is specified, the driver uses the default time zone, which is that of the virtual machine running the application.
When you call with setTimestamp(int parameterIndex, Timestamp x) the JDBC driver uses the time zone of the virtual machine to calculate the date and time of the timestamp in that time zone. This date and time is what is stored in the database, and if the database column does not store time zone information, then any information about the zone is lost (which means it is up to the application(s) using the database to use the same time zone consistently or come up with another scheme to discern timezone (ie store in a separate column).
For example: Your local time zone is GMT+2. You store "2012-12-25 10:00:00 UTC". The actual value stored in the database is "2012-12-25 12:00:00". You retrieve it again: you get it back again as "2012-12-25 10:00:00 UTC" (but only if you retrieve it using getTimestamp(..)), but when another application accesses the database in time zone GMT+0, it will retrieve the timestamp as "2012-12-25 12:00:00 UTC".
If you want to store it in a different timezone, then you need to use the setTimestamp(int parameterIndex, Timestamp x, Calendar cal) with a Calendar instance in the required timezone. Just make sure you also use the equivalent getter with the same time zone when retrieving values (if you use a TIMESTAMP without timezone information in your database).
So, assuming you want to store the actual GMT timezone, you need to use:
Calendar cal = Calendar.getInstance(TimeZone.getTimeZone("GMT"));
stmt.setTimestamp(11, tsSchedStartTime, cal);
With JDBC 4.2 a compliant driver should support java.time.LocalDateTime (and java.time.LocalTime) for TIMESTAMP (and TIME) through get/set/updateObject. The java.time.Local* classes are without time zones, so no conversion needs to be applied (although that might open a new set of problems if your code did assume a specific time zone).
I think the correct answer should be java.sql.Timestamp is NOT timezone specific. Timestamp is a composite of java.util.Date and a separate nanoseconds value. There is no timezone information in this class. Thus just as Date this class simply holds the number of milliseconds since January 1, 1970, 00:00:00 GMT + nanos.
In PreparedStatement.setTimestamp(int parameterIndex, Timestamp x, Calendar cal)
Calendar is used by the driver to change the default timezone. But Timestamp still holds milliseconds in GMT.
API is unclear about how exactly JDBC driver is supposed to use Calendar. Providers seem to feel free about how to interpret it, e.g. last time I worked with MySQL 5.5 Calendar the driver simply ignored Calendar in both PreparedStatement.setTimestamp and ResultSet.getTimestamp.
The answer is that java.sql.Timestamp is a mess and should be avoided. Use java.time.LocalDateTime instead.
So why is it a mess? From the java.sql.Timestamp JavaDoc, a java.sql.Timestamp is a "thin wrapper around java.util.Date that allows the JDBC API to identify this as an SQL TIMESTAMP value". From the java.util.Date JavaDoc, "the Date class is intended to reflect coordinated universal time (UTC)". From the ISO SQL spec a TIMESTAMP WITHOUT TIME ZONE "is a data type that is datetime without time zone". TIMESTAMP is a short name for TIMESTAMP WITHOUT TIME ZONE. So a java.sql.Timestamp "reflects" UTC while SQL TIMESTAMP is "without time zone".
Because java.sql.Timestamp reflects UTC its methods apply conversions. This causes no end of confusion. From the SQL perspective it makes no sense to convert a SQL TIMESTAMP value to some other time zone as a TIMESTAMP has no time zone to convert from. What does it mean to convert 42 to Fahrenheit? It means nothing because 42 does not have temperature units. It's just a bare number. Similarly you can't convert a TIMESTAMP of 2020-07-22T10:38:00 to Americas/Los Angeles because 2020-07-22T10:30:00 is not in any time zone. It's not in UTC or GMT or anything else. It's a bare date time.
java.time.LocalDateTime is also a bare date time. It does not have a time zone, exactly like SQL TIMESTAMP. None of its methods apply any kind of time zone conversion which makes its behavior much easier to predict and understand. So don't use java.sql.Timestamp. Use java.time.LocalDateTime.
LocalDateTime ldt = rs.getObject(col, LocalDateTime.class);
ps.setObject(param, ldt, JDBCType.TIMESTAMP);
You can use the below method to store the timestamp in database specific to your desired zone/zone Id.
ZonedDateTime zdt = ZonedDateTime.now(ZoneId.of("Asia/Calcutta")) ;
Timestamp timestamp = Timestamp.valueOf(zdt.toLocalDateTime());
A common mistake people do is use LocaleDateTime to get the timestamp of that instant which discards any information specif to your zone even if you try to convert it later. It does not understand the Zone.
Please note Timestamp is of the class java.sql.Timestamp.
For Mysql, we have a limitation.
In the driver Mysql doc, we have :
The following are some known issues and limitations for MySQL
Connector/J: When Connector/J retrieves timestamps for a daylight
saving time (DST) switch day using the getTimeStamp() method on the
result set, some of the returned values might be wrong. The errors can
be avoided by using the following connection options when connecting
to a database:
useTimezone=true
useLegacyDatetimeCode=false
serverTimezone=UTC
So, when we do not use this parameters and we call setTimestamp or getTimestamp with calendar or without calendar, we have the timestamp in the jvm timezone.
Example :
The jvm timezone is GMT+2.
In the database, we have a timestamp : 1461100256 = 19/04/16 21:10:56,000000000 GMT
Properties props = new Properties();
props.setProperty("user", "root");
props.setProperty("password", "");
props.setProperty("useTimezone", "true");
props.setProperty("useLegacyDatetimeCode", "false");
props.setProperty("serverTimezone", "UTC");
Connection con = DriverManager.getConnection(conString, props);
......
Calendar nowGMT = Calendar.getInstance(TimeZone.getTimeZone("GMT"));
Calendar nowGMTPlus4 = Calendar.getInstance(TimeZone.getTimeZone("GMT+4"));
......
rs.getTimestamp("timestampColumn");//Oracle driver convert date to jvm timezone and Mysql convert date to GMT (specified in the parameter)
rs.getTimestamp("timestampColumn", nowGMT);//convert date to GMT
rs.getTimestamp("timestampColumn", nowGMTPlus4);//convert date to GMT+4 timezone
The first method returns : 1461100256000 = 19/04/2016 - 21:10:56 GMT
The second method returns : 1461100256000 = 19/04/2016 - 21:10:56 GMT
The third method returns : 1461085856000 = 19/04/2016 - 17:10:56 GMT
Instead of Oracle, when we use the same calls, we have :
The first method returns : 1461093056000 = 19/04/2016 - 19:10:56 GMT
The second method returns : 1461100256000 = 19/04/2016 - 21:10:56 GMT
The third method returns : 1461085856000 = 19/04/2016 - 17:10:56 GMT
NB :
It is not necessary to specify the parameters for Oracle.
It is specific from your driver. You need to supply a parameter in your Java program to tell it the time zone you want to use.
java -Duser.timezone="America/New_York" GetCurrentDateTimeZone
Further this:
to_char(new_time(sched_start_time, 'CURRENT_TIMEZONE', 'NEW_TIMEZONE'), 'MM/DD/YY HH:MI AM')
May also be of value in handling the conversion properly. Taken from here
If your problem is to get a timestamp of the local zone, you can use this:
Timestamp.from(Instant.now()).toLocalDateTime()
I'm using DateTime in order to store timestamps on my server in UTC-Time:
// #Entity ..
#NotNull
#Column(name="DATE")
#Type(type="org.jadira.usertype.dateandtime.joda.PersistentDateTime")
private DateTime date;
During the server boot up I'm doing this:
DateTimeZone.setDefault(DateTimeZone.UTC);
to make sure that new DateTime() will always be in UTC-Time and this is how I prepare a date to get stored:
DateTime utc = new DateTime();
utc = utc.dayOfMonth().roundFloorCopy();
DateTime thisMonday = utc.withDayOfWeek(DateTimeConstants.MONDAY);
DateTime thisTuesday = thisMonday.plusDays(1);
If I'm debugging this I see e.g.
2015-08-31 00:00:00 and 2015-09-01 00:00:00
but as I look into the database I see that
2015-08-31 02:00:00 and 2015-09-01 02:00:00
got stored there. It's +2h which is my local UTC offset (Berlin/Vienna).
Why is this happening and how can I make sure that my server stores all times in UTC?
You are using Jadira for converting JodaTime types to SQL date/time types. Use these JPA/Hibernate properties to tell Jadira what time zone should be applied when sending data to the DB
<properties>
<property name="jadira.usertype.javaZone" value="UTC" /> <!-- or "jvm" to use your default JVM TZ, explicit Europe/Berlin or +02:00 etc. -->
<property name="jadira.usertype.databaseZone" value="UTC" /> <!-- or "jvm" to use your default JVM TZ or +02:00 etc. But you'd better not use an explicit TZ with a DST change -->
</properties>
See Jadira User Guide for details.
Other thing is that maybe your DB is using your connection information to display you the timestamps in your time zone? That depends on which DB it is and which tool you use to connect. SQL Developer (for Oracle DB) is aware of your computer's TZ and sets the connection TZ to that.
Im receiving util.Date 's from twitter4j getCreatedAt() method.
Date d = twitter.getCreatedAt();
System.out.println(d);
Out: 'Mon Feb 17 00:10:34 PST 2014'
I'm trying to convert that to a sql.Date including the time. With the code I'm using right now, querying mysql from terminal shows a date like:
2014-02-16 00:00:00
Here's the code in the Tweet Model. (Using Play 2, btw)
#Id
public long id;
#Formats.DateTime(pattern="yyyy-MM-dd HH:mm:ss")
public Date date;
When a status comes in I construct it like so:
this.date = new java.sql.Date(status.getCreatedAt().getTime());
I think it could possibly be something to do with the time zones?
java.sql.Date just keeps the normalized date, see this from Oracle documentation:
To conform with the definition of SQL DATE, the millisecond values
wrapped by a java.sql.Date instance must be 'normalized' by setting
the hours, minutes, seconds, and milliseconds to zero in the
particular time zone with which the instance is associated.
If you want to use time with the date you have to use java.sql.Timestamp instead of java.sql.Date
I managed in JAVA to store a calendar into a mysql DATETIME field
To fetch this value
entry.date = Calendar.getInstance(TimeZone.getTimeZone("UT"));
entry.date.setTime(rs.getDate(DBBLogEntries.entDate));
Where the entry.date is a java.util.Calendar
In the database the value is this: '2012-07-07 07:18:46'
I store all date values in a unique timezone in the db. ready to make all the extra work required to add or substract hours depending on the country from wich the request is comming.
The problem is that it brings the date but doesn't seem to brinng me the time.
Any sugestion please?
Thanks in advance.
Probably because Java has a different date format than mysql format(YYYY-MM-DD HH:MM:SS)
Visit the link :
http://www.coderanch.com/t/304851/JDBC/java/Java-date-MySQL-date-conversion
You may use SimpleDateFormat as follows.
java.util.Date dt = new java.util.Date();
java.text.SimpleDateFormat sdf =
new java.text.SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
String dateTime = sdf.format(dt);
You should read a timestamp from the ResultSet object.
java.sql.Timestamp ts = rs.getTimestamp( DBBLogEntries.entDate );
Which returns a Timestamp instance that includes date and time.
don't use Java.util.Date ,use the Java.sql.Date.
Are you using the MySql DATE type? This does not preserve the time component.
http://dev.mysql.com/doc/refman/5.5/en/datetime.html
Alternatively how are you retrieving the date from the db?