i have table "news", that has a column called dateNews (type date )
in PostgreSQL the date has the following format : 2014-04-16
but in my jpa web service the format is the following : "2014-04-16T00:00:00+03:00"
how can i format my date to the following format : dd/mm/yyyy
and where should i do it is it in my PostgreSQL database or in my jpa web service ?
This conversion should be done in the service, not at the database level. Make sure your field is type java.sql.Date and use java.text.SimpleDateFormat.
see http://docs.oracle.com/javase/7/docs/api/java/text/SimpleDateFormat.html
Main reasons to add this at the service level are extensibility and maintainability. You want a single point where you do all this formatting, probably based on user preferences. You don't want to add this to every query you are doing, and maintaining the format throughout those queries.
Use to_char() to output a formated string (text):
SELECT to_char(datenews, 'dd/mm/yyyy') FROM news;
Related
In as Spring Boot app, I am reading LocalDate from a JSON in dd/MM/yyyy format e.g. 15/03/2009 and while reading, I created them to a request. The format in the request is dd/MM/yyyy.
*ProductRequest:
#JsonFormat(shape = JsonFormat.Shape.STRING, pattern = "dd/MM/yyyy")
private LocalDate buyingDate;
And then I save the date fields to database via my Entity. It also has the same format as shown below:
*ProductEntity:
#JsonFormat(shape = JsonFormat.Shape.STRING, pattern = "dd/MM/yyyy")
private LocalDate buyingDate;
But the data in the database is shown in yyyy-MM-dd format. I think it is default format for LocalDate, but I need to be clarified about these points: Could you helps me please?
1. Does LocalDate always kept in yyyy-MM-dd format in the database independently from it had in JSON file and in Request?
2. As far as I see, the format while reading the data to ProductRequest is related to the usage when displaying data using this class (ProductRequest). IS that true?
3. Is there any need to use #JsonFormat(shape = JsonFormat.Shape.STRING, pattern = "dd/MM/yyyy") for the date field in ProductEntity? As far as I see, it does not make any sense for the format when saving to database. So, if we do not display or use date field from this entity, then there is no need to use format annotation. Is that true?
Does LocalDate always kept in yyyy-MM-dd format in the database independently from it had in JSON file and in Request?
The JSON representation you use has nothing to do with how data is stored in the database[*]. Each database vendor (Oracle, MySQL, Postgres, SQLServer, etc) has its own way of storing date and date+time values. It's the job of your application or framework (eg, Hibernate) to translate from Java types such as LocalDate into the appropriate format for SQL statements. So the answer is "yes," the format of a date in the application is independent from how it's stored in a database.
As far as I see, the format while reading the data to ProductRequest is related to the usage when displaying data using this class (ProductRequest). IS that true?
Only if you serialize ProductRequest back out to JSON. #JsonFormat applies to both reading (deserializing) and writing (serializing) from/to JSON.
Is there any need to use #JsonFormat(shape = JsonFormat.Shape.STRING, pattern = "dd/MM/yyyy") for the date field in ProductEntity? As far as I see, it does not make any sense for the format when saving to database. So, if we do not display or use date field from this entity, then there is no need to use format annotation. Is that true?
That is correct. In fact, it's very misleading to see that annotation in an entity[*]
[1] Unless you are using a database that natively understands JSON and/or stores data internally as JSON.
Currently I have a Spring application with some resources that receives different kinds of data. One of the data attributes its a Timestamp and the value is sent in the request. I am using Spring Data Jpa to persist the data in a Postgresql database.
This is how I have my object:
#JsonProperty(value = "control_initial_timestamp")
#Temporal(TemporalType.TIMESTAMP)
#JsonFormat(shape = JsonFormat.Shape.STRING, pattern = "yyyy-MM-dd HH:mm:ss.SSS")
#Column(name = "ctrl_init_ts")
private Date controlInitTimestamp;
... Setters and Getters ...
My Request looks like this:
"record_insert_timestamp" : "2020-05-18 09:53:24.475"
In the database I receive this: 2020-05-18 05:53:24.475000
If you noticed, it changes the time of the whole timestamp.
Also, with Spring Data, all I am doing is object.save(objectlist); I am not doing any specially query.
Please let me know if I am missing anything.
Thanks,
Is the timezone different between your app server and database server? You can enforce timezone for date serialization in JsonFormat by passing timezone
I got the answer. Not what I expected, but actually how it works.
Databases will store Timestamps as per their timezone location of their remote server location and timezone, to maintain a correlation between all timestamps in the DB/tables/views...etc .
When retrieving the timestamp, if you have configure your current location or timezone or remote server timezone, then it will convert to that specific timezone.
There is no direct way to manipulate this, but its actually how it works.
Thanks,
Let us know what is the datatype defined in database (timestamptz/timestamp)
Refer below link on -- PostgreSQL timestamp
https://www.postgresqltutorial.com/postgresql-timestamp/
I have created one entity in jhipster using jhipster-jdl.jh file which is as shown below:
entity EmployeeLeave{
appliedDate LocalDate required,
fromDate LocalDate required,
toDate LocalDate required,
status String
}
From these fields i want appliedDate as today's date in database(MySql).
I have tried this from Angular side in jhipster code but none helps well.
Is there any way so that when creating a record for employeeLeave there should be always appliedDate equals to today's date.
Preferably i want solution from Angular side. Other solutions are also welcomed.
Technologies:
Database: Mysql,
Spring-boot,
Angular 4,
Jhipster.
You can initialize your date inside your class :
public class EmployeeLeave{
LocaleDate yourDate = LocaleDate.now();
//other fields
}
So, appliedDate will always be today's date. I am using Java 8 but the idea is here.
LocaleDate.now() is server time. If server is in another time zone than user, may insert incorrect date.
Isn't better to define date in .controller.js like:
var now = new Date();
vm.employeeLeave.appliedDate=now;
vm.isSaving = true;
EmployeeLeave.update(vm.employeeLeave, onSaveSuccess, onSaveError);
?
I have date stored in mysql db as DATETIME and the value is stored in db as
"2016-09-09 15:56:26"
I wanted to display in same format, I am using Jersey 1.19 with POJOMapping and I used Date format in pojo, but the value shown in API is as:
"createdDt":1473454586000
What is the right approach to display correct date format in GET API, should I use String?
We have an app in which we are using hibernate with mysql db.
We have a db script import.sql which have some insert into statements and we also have some date fields in db like start_date end_date in which we are string dates in default format, that is,YYYY-MM-DD.
Now issue is at the time of retrieving/comparing dates hibernates showing strange behaviour for example suppose if we have a date 2012-01-30 then hibernate reads in proper format that is, Jan 30 2012, but if we have a date like 2012-02-06 then hibernate reads as June 02 2012. my DAO for comparing and retrieving result is as follows
public final List<Record> getPastRecords(final java.util.Date currentDate) {
List<Record> pastRecord = session.createCriteria(Record.class)
.add(Restrictions.lt("endTime", currentDate))
.setResultTransformer(Criteria.DISTINCT_ROOT_ENTITY).list();
return pastRecord;
}
Any idea what I am doing wrong?
without detailed code explanation guessing what may be the problem is very hard through i guess
it may be because of java.util.Date try to use java.sql.Date as when you call methods/constructors of libraries that deal with database better to use wrapper of java.util.Date which is java.sql.Date.
refer http://www.theresearchkitchen.com/archives/58