Trying to save Date in Mongo db in java apllication but it is saving one day before i have tried code mentioned below.
I tried creating a custom conversion using Zonal Date Time Converter please help if someone has faced issue like that.
#Bean
public CustomConversions customConversions(){
List<Converter<?,?>> converters = new ArrayList<Converter<?,?>>();
converters.add(new DateToZonedDateTimeConverter());
converters.add(new ZonedDateTimeToDateConverter());
return new CustomConversions(converters);
}
#Bean
public MongoTemplate getMongoTemplate() throws UnknownHostException {
MappingMongoConverter converter = new MappingMongoConverter(
new DefaultDbRefResolver(getMongoDbFactory()), new MongoMappingContext());
converter.setCustomConversions(customConversions());
converter.afterPropertiesSet();
return new MongoTemplate(getMongoDbFactory(), converter);
}
class DateToZonedDateTimeConverter implements Converter<Date, ZonedDateTime> {
#Override
public ZonedDateTime convert(Date source) {
return source == null ? null : ofInstant(source.toInstant(), systemDefault());
}
}
class ZonedDateTimeToDateConverter implements Converter<ZonedDateTime, Date> {
#Override
public Date convert(ZonedDateTime source) {
return source == null ? null : Date.from(source.toInstant());
}
}
MongoDB will convert your date to GMT time during saving. But if you pull your date again to local time zone you will have appropriate time.
If you have application intended for different geo locations with different zones you could use GMT time zone on backend and local time zone on frontend. If zone is important for your business case you can save in mongodb both GMT time and zone separately.
You will not be able to save zone inside date object in MongoDB.
Its just looks bad but its good and I will try to explain.
Suppose you want to save date from:
Germany/Berlin as local date 2019-09-20T00:20:00.000 GMT+1
MongoDB will convert this date to GMT and you will see in database ISODate("2019-09-19T23:20:00.000Z") (look like one day before same as
you describe)
If you fetch this mongo document and deserialize to Java object with
date you could print date and you will see:
In Germany and GMT+1 locations you will print what you expect 2019-09-20T00:20:00.000 GMT+1 because Java java.util.Date automatically convert GMT to local time
In other locations you will see other times for example in London you will see 2019-09-19T23:20:00 GMT and its ok because London is 1
hour before Berlin
Solution depending of your case but common mistake is date picker which provide local date with time 00:00 and conversion create problems. In this case just send UTC date from frontend side.
You have 2 common cases:
You need to save time of online call (you don't need location, some members will be from Japan, some from Germany and some from Brasil)
In this case you could send local time from your time picker and mongo will convert to GMT. When clients fetch dates you will return UTC and they will have automatic conversion to local times and all clients will see correct time
You need to save time of face to face appointment (you need to save location because some members will be from Japan, some from Germany and some from Brasil and suppose they have to know what is local time)
In this case you could save date in one field and tiemzone in second filed. This will ensure what you want.
If you have some another case or some another problem please share more details.
I am working on Spring MVC project. It is an quasi online system where each client will install our system (Tomcat n Mysql will get installed through an installer) on their machine. They will download the data by connecting their machine to internet. Once data get downloaded they can disconnect from internet.
By considering above scenario, we want to validate the system date n time is correct according to time zone. I have checked How to get local time of different time zones?, The code :
java.util.TimeZone tz = java.util.TimeZone.getTimeZone("IST");
java.util.Calendar c = java.util.Calendar.getInstance(tz);
System.out.println(c.get(java.util.Calendar.HOUR_OF_DAY)+":"+c.get(java.util.Calendar.MINUTE)+":"+c.get(java.util.Calendar.SECOND));
Give the same time of the system. I want something which will tell time according to the time zone. Same as like when we set time zone on OS clock it will automatically set the correct date and time according to that time zone.
Implementation like this:
Date accurateTimeZoneDate = //HERE I WANT SOMETHING TO GET DATE ACCORDING TO TIME ZONE.
Date machineCurrentDate = new Date();
if(accuratetimeZoneDate == machineCurrentDate)
{
//machine date and time zone date is correct.
}
else
{
//machine date and time zone date is NOT correct.
}
Update
We have tried this:
Daily it is mandatory to connect the system to internet so that application will ping to an central ntp and get the time and validate. once validation is successful then they can disconnect from internet. But in this case after validation they switch to some old date and use the expired content.
Ok if you want system time and date then you should try new Date().
it will give current date time with timezone.
Instead of using Calendar, you should use new Date()
System.out.println("Current Date And Time"+ new Date());
I'm trying to write code to interoperate with a third-party-developed database using Java and MySQL. This database has a field that stores a time stamp in a DATETIME field as a UTC date. The timezone for the server on which both the database and client run is set to a non-UTC zone (Europe/London), so by default the timestamp is read back incorrectly as if it were a local time. I'm trying to write code to read it back as UTC.
I have read several similar questions here, but none of them have an answer that works for me:
MySQL - how to store time with correct timezone? (from Java)
How to store a java.util.Date into a MySQL timestamp field in the UTC/GMT timezone?
Date in UTC in mysql
How do I set the time zone of MySQL?
Unfortunately, I cannot change any server settings, so I have tried using the connection's "time_zone" variable to set the database server to use UTC and the optional Calendar parameter to ResultSet.getTimestamp to retrieve the date, but this has no effect on the result. Here is my code:
private static final Calendar UTCCALENDAR = Calendar.getInstance (TimeZone.getTimeZone (ZoneOffset.UTC));
public Date getDate ()
{
try (Connection c = dataSource.getConnection ();
PreparedStatement s = c
.prepareStatement ("select datefield from dbmail_datefield where physmessage_id=?"))
{
fixTimeZone (c);
s.setLong (1, getPhysId ());
try (ResultSet rs = s.executeQuery ())
{
if (!rs.next ()) return null;
return new Date (rs.getTimestamp(1,UTCCALENDAR).getTime ()); // do not use SQL timestamp object, as it fucks up comparisons!
}
}
catch (SQLException e)
{
throw new MailAccessException ("Error accessing dbmail database", e);
}
}
private void fixTimeZone (Connection c)
{
try (Statement s = c.createStatement ())
{
s.executeUpdate ("set time_zone='+00:00'");
}
catch (SQLException e)
{
throw new MailAccessException ("Unable to set SQL connection time zone to UTC", e);
}
}
The database field I'm trying to read has a value stored in it as follows:
mysql> select * from dbmail_datefield where physmessage_id=494539;
+----------------+--------+---------------------+
| physmessage_id | id | datefield |
+----------------+--------+---------------------+
| 494539 | 494520 | 2015-04-16 10:30:30 |
+----------------+--------+---------------------+
But unfortunately, the result comes out as BST not UTC:
java.lang.AssertionError: expected:<Thu Apr 16 11:30:30 BST 2015> but was:<Thu Apr 16 10:30:30 BST 2015>
Your client getDate() code looks correct as far as it goes. I think you also need to get the MySQL Connector/J JDBC driver to treat the dates stored in the table as UTC dates, to avoid a spurious time zone conversion. This means setting the effective server time zone, in addition to the client session time zone and Calendar used for JDBC getTimestamp calls as you're doing.
Take a look at the values you got in your failed assertion, and which direction the error is in:
expected:<Thu Apr 16 11:30:30 BST 2015> but was:<Thu Apr 16 10:30:30 BST 2015>
What you got back was 10:30 BST, which is 9:30 GMT. This is consistent with the database treating that 10:30 in the table as a BST value and spuriously converting it to GMT for you, before you parse it as a GMT date. That's the opposite direction of a GMT value being spuriously converted to BST.
This may be a JDBC-specific issue, because JDBC requires that time times be converted to the local zone. (Where the MySQL C API doesn't, probably because C's classic time types are not zone-aware the way Java's are.) And it needs to know what zone it's converting from, as well. The MySQL TIMESTAMP type is always stored as UTC. But that's not stated for the DATETIME type. I think that implies that MySQL is going to interpret DATETIME column values as being in the server's time zone. Which you mentioned as being set to BST, and that's consistent with the direction of the shift shown in your assertion error message.
The time_zone session variable you set is telling the MySQL server what your client machine's time zone is, but it doesn't affect what the server thinks its own time zone is. That can be overridden with the serverTimezone JDBC connection property. On your connection, set the serverTimezone to UTC, and make sure useLegacyDatetimeCode is off. (And look through the other zone-related properties if that doesn't work.) See if that gets your dates to come through as UTC with the same calendar field values as in the database.
Be aware that this is going to change the interpretation of other DATETIME values in your database: they're all going to look like UTC dates now (in the context of your JDBC connection). Whether that's correct is going to depend on how they were populated initially. While your client code will have the behavior you want, I don't know if this system as a whole can be made to behave fully consistently without setting the server's time zone to UTC at the server level. Basically, if it doesn't have its zone set to UTC, it's not fully configured for the behavior you want, and you're kludging around it.
Maybe you can use JodaTime as follows;
private static final Calendar UTCCALENDAR = Calendar.getInstance (TimeZone.getTimeZone (ZoneOffset .UTC));
public Date getDate ()
{
try (Connection c = dataSource.getConnection ();
PreparedStatement s = c
.prepareStatement ("select datefield from dbmail_datefield where physmessage_id=?"))
{
s.setLong (1, getPhysId ());
try (ResultSet rs = s.executeQuery ())
{
if (!rs.next ()) return null;
DateTime dt = new LocalDateTime(rs.getTimestamp(1,UTCCALENDAR).getTime ()).toDateTime(DateTimeZone.forID("Europe/London"));
return dt.toDate(); }
}
catch (SQLException e)
{
throw new MailAccessException ("Error accessing dbmail database", e);
}
}
EDIT:
java.util.Date is not TimeZone agnostic. The method toDateTime takes care of TimeZone and DST so you don't care about it
The following code:
public static void main(String[] args) {
// 29/March/2015 1:05 UTC
DateTime now = new DateTime(2015, 3,29,1,5,DateTimeZone.UTC);
// Pre DST 29/March/2015 0:30 UTC
DateTime preDst = new DateTime(2015, 3,29,0,30,DateTimeZone.UTC);
System.out.println("1:05 UTC:"+now);
System.out.println("0:30 UTC:"+preDst);
DateTimeZone europeDTZ = DateTimeZone.forID("Europe/London");
DateTime europeLondon = now.toDateTime(europeDTZ);
System.out.println("1:05 UTC as Europe/London:"+europeLondon);
DateTime europeLondonPreDst = preDst.toDateTime(europeDTZ);
System.out.println("0:30 UTC as Europe/London:"+europeLondonPreDst);
}
Will print:
1:05 UTC:2015-03-29T01:05:00.000Z
0:30 UTC:2015-03-29T00:30:00.000Z
1:05 UTC as Europe/London:2015-03-29T02:05:00.000+01:00
0:30 UTC as Europe/London:2015-03-29T00:30:00.000Z
If you can see JodaTime takes care of DST.
Your best bet, in my view, is to tell MySQL to use GMT and handle all local time issues in your application code, not your database. The values in the database would always be GMT, full stop, which is unambiguous. As you say, with daylight savings time (summer time) adjustments, you can end up with the same value in your database for what is, to us humans, two different times.
This also makes the database portable. If you move to North America and start using MySQL set to (say) Central time, all of a sudden the values in your database seem to have moved several hours. I had that issue with a database I inherited which was using the server's local time, when I moved it from the east coast of the U.S. to the west coast, not having thought to check whether MySQL was slaved to the machine's zone...
long t = 1351382400000; // the timestamp in UTC
String insert = "INSERT INTO my_table (timestamp) VALUES (?)";
PreparedStatement stmt = db.prepareStatement(insert);
java.sql.Timestamp date = new Timestamp(t);
stmt.setTimestamp(1, date);
stmt.executeUpdate();
.....
TimeZone timezone = TimeZone.getTimeZone("MyTimeZoneId");
Calendar cal = java.util.Calendar.getInstance(timezone);
String select = "SELECT timestamp FROM my_table";
// some code omitted....
ResultSet rs = stmt.executeQuery();
while (rs.next()) {
java.sql.Timestamp ts = rs.getTimestamp(1);
cal.setTimeInMillis(ts.getTime());
System.out.println("date in db: " + cal.getTime());
}
If you want to use timezone you can read column as UTC.
ZonedDateTime zdt = ZonedDateTime.of(rs.getTimestamp(1).toLocalDateTime(), ZoneOffset.UTC);
Next you can change to whatever timezone you want using:
zdt = zdt.withZoneSameInstant(ZoneId.of(
TARGET_ZONE));
If you want only to read Date and do not care about zones at all use only:
LocalDateTime ldt = rs.getTimestamp(1).toLocalDateTime()
You will obtain LocalDateTime without timezone.
If you have to return java.util.Date use:
Date.from(ldt.atZone(ZoneOffset.UTC).toInstant());
Don't think about converting or adapting time zone. Don't think about the TZ the mysql uses to store your timestamps or anythink like that. Those things are already handled.
There are three things that you must handle: INPUT, OUTPUT and bugs.
INPUT
When a user enters a date (in a form) without an explicit time zone you have to know what TZ did he intend to use. You can use a SimpleDateFormat object with time zone set to solve this. You don't have to convert the input date, you have to 'interpret' it correctly. Once you have a correctly interpreted Date or timestamp you are done with input.
Input is not only user input, includes configuration files too.
OUTPUT
The same here. Forget about what TZ have your Date objects and timestamps have none, they are just milliseconds since epoch. You have to format your dates to the TZ the user expects so he understand them.
Bugs
You may have bugs in your code related to TZ, but libraries may have them too!!
I noticed mysql java driver failed to communicate the client timezone to the server.
This command s.executeUpdate ("set time_zone='+xx:yy'"); is the workaround but you are using it wrong. You have to tell the server with it the TZ the client is using, before both inserting and querying. The variable is stored in the session. Maybe you may automatize it on your connection pool config.
This is needed so the server know what TZ the client need to use to read or write. This is not dependent on server TZ. It does not mean "store this date in UTC", it does mean "this date I am giving to you is UTC" and "Send me result sets in UTC". No matter you are using Date class with it's internal TZ, the driver screws it up, you would need to set that session variable.
By default it assumes client TZ is the same as server TZ so you shouldn't need to worry about it as you said they are the same.
From few days I am fighting with different Timezone issues of server and GWT client. but cannot get any success.
Scenario is Server is in UTC timezone let say Client A is in IST timezone.
When client select a date (with time) I pushed to server but date is automatically changed to server's timezone. I dig around this issue and I found multiple solutions like
create custom serializer (No idea how to do that can't found any proper example)
transfer date as a string to server and convert it to server timezone and store it. and when fetching data convert again from server's timezone to client local timezone. sounds good idea.
So my query is.
Any other solutions?
which is best way to manage this ?
any sample code or link?
Simply format the date in UTC format at client side and pass the date as string to the server and store the data in UTC format in database as well.
On the server side everything would be fine, since formatting the date would use the timezone of the server, which is what the date is stored in. On the client side, however, GWT will use the timezone of the client machine, and so there could be a discrepancy.
Sample code:
DateTimeFormat f = DateTimeFormat.getFormat("MMM dd yyyy");
TimeZoneConstants t = (TimeZoneConstants) GWT.create(TimeZoneConstants.class)
TimeZone est = TimeZone.createTimeZone(t.americaNewYork());
int offset = est.isDaylightTime(date) ? +240 : +300;
TimeZone tz = TimeZone.createTimeZone(offset);
String date = f.format(user.getBirthDate(), est);
There are a few other possible solutions, but one of these two might do the trick.
How do I get GWT DateTimeFormat to display using the server TimeZone, rather than the client's?
In my Android application server will return some UTC date in following format(yyyy-MM-dd HH:mm:ss) 24hours and I need to convert those time into user's TimeZone for example CST, IST.
I did the following code but I do know is it correct or not, please assist me to do the time zone conversion in right way.
I get UTC date as json string and converting into user's time zone format and showing Android side
private static Date utcDate;
private static DateFormat expireFormat = new SimpleDateFormat(
"yyyy-MM-dd HH:mm:ss");
try {
expireFormat.setTimeZone(TimeZone.getTimeZone("UTC"));
utcDate = expireFormat.parse("2014-04-01 10:32:00");
System.out.println(TimeZone.getDefault().getID());
expireFormat.setTimeZone(TimeZone.getTimeZone(TimeZone.getDefault().getID()));
System.out.println(expireFormat.format(utcDate));
} catch (ParseException e) {
e.printStackTrace();
}
output of the code:
Asia/Calcutta
2014-04-01 16:02:00
The overall approach is OK if a re-formatted String is really what you're trying to get.
There are some issues though
SimpleDateFormat is not a threadsafe class. Setting it to a static field inside a server is a problem!
Same as #1 regarding using a static field to hold the intermediate Date object.
Is "CST" China Standard Time? Central Standard Time (US or Australia)? Cuba Standard Time? Three letter abbreviations TimeZone are bad news in general. Try to use an Olson Name or Alias if at all possible.
Is this the server side or the android? If it's a server, you could probably benefit from the new Java 8 API for DateTime handling.