The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
Tim Holloway wrote:An Epoch has nothing to do with operating systems or data representations.
In horological terms, an Epoch is a fixed reference point in time (and generally also in space). So the Unix Epoch has been fixed at midnight, January 1, 1970 at the Greenwich Observatory in England (which I believe aligns longitudinally with Paris France). The Unix internal datetime structures count time as an integral number of units from that point in space and time. Java uses Unix as its basis, so java.util.Date contains a signed long integer internally containing the number of milliseconds since that epoch.
There are at least 2 other commonly-used epochs. The most widely used one is, of course the Christian Era, dating from midnight UTC at the beginning of the Roman Year (?) January 1 of the ecclesiastically-defined birth of the Christian Messiah. The exact timing here has been adjusted multiple times throughout history and purists will note that the ecclesiastical birth year and the likely actual birth year differ by approximately 4 years.
The gold standard for epochs is probably the astronomical Julian Day. It is measured from noon Universal Time on January 1, 4713 BC. presumably since that's when the world was created, and if not, far enough back that most astronomical observations in recorded history are a positive number. Unlike other systems, there are no hours/minutes/seconds in Julian Days, just decimal fractions of a day.
Oracle is keeping date/time values in at least 2 different forms, depending on precision: day precision or seconds precision. The YYYY-MM-DD format is a display format unrelated to whatever internal storage format Oracle is using. And, it should be noted that YYYY-MM-DD is the preferred date display format for ALL SQL DBMSs. It doesn't have the confusion of the US-vs-world MM/DD/YY, DD/MM/YY, doesn't have Y2K issues, and collates nicely as text.
So in short, neither Java nor Oracle are keeping dates internally in a specific text format. That's just how they display them. Java, of course, has extensive date formatting services.
And finally, note that as I said initially, dates and times are best considered in space as well as time. The locale that you're in determines not only the preferred human format for date and time display, but also the timezone offset from the internal value. Some databases actually have different date/time data types to allow for local or UTC time values.
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
Tim Holloway wrote:There should be no difference between one database and another unless one of them has defined the date as a text database data type instead of as a date/time data type.
However, I'd expect that JSON would probably default to formatting date/time values in Unix form (Actually, I think there's an ISO standard that defines "Unix" date/time text formatting). SQL*PLUS, on the other hand, I'd expect to show dates and times in SQL format, even though the actual data in the database was the same for both applications.
Dave Tolls wrote:What date value are you referring to exactly?
The values in the classes in the OP are all Dates, and they have no format at all. They're just a long, essentially.
So if there's an issue with how that value is being displayed somewhere then that is where the issue lies, and is nothing to do either with Oracle or JDBC.
Dave Tolls wrote:What date value are you referring to exactly?
The values in the classes in the OP are all Dates, and they have no format at all. They're just a long, essentially.
So if there's an issue with how that value is being displayed somewhere then that is where the issue lies, and is nothing to do either with Oracle or JDBC.
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
No, according to Wikipedia Paris is 2° 21″ east of Greenwich.Tim Holloway wrote:. . . Greenwich Observatory . . . aligns longitudinally with Paris France . . . .
Jack Tauson wrote:
In both the databases, the dates have this value : 11/09/2016 08:10:00 PM
Webservice call(JSON Response) in TEST returns Unix time which is messing my UI code and in production it returns it in YYYY-MM-DD format which is fine with my UI. UI and Java code is same for both TEST and Production servers. So, I was wondering what's causing this issue.
Dave Tolls wrote:
It is whatever is turning the Date into a String for the Json response.
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
Dave Tolls wrote:
Jack Tauson wrote:
In both the databases, the dates have this value : 11/09/2016 08:10:00 PM
Webservice call(JSON Response) in TEST returns Unix time which is messing my UI code and in production it returns it in YYYY-MM-DD format which is fine with my UI. UI and Java code is same for both TEST and Production servers. So, I was wondering what's causing this issue.
OK, so my point still stands.
It's not the bit of code you just posted that is the problem.
It is whatever is turning the Date into a String for the Json response.
Jack Tauson wrote:In both the databases, the dates have this value : 11/09/2016 08:10:00 PM
Paul Clapham wrote:
Jack Tauson wrote:In both the databases, the dates have this value : 11/09/2016 08:10:00 PM
In database terminology, that is not a DATE. That is a TIMESTAMP. Unfortunately the java.util.Date class represents a TIMESTAMP rather than a DATE.
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
Jack Tauson wrote:
The reason I am confused is because that thing which is converting Date into String for Json response is same for TEST and Production Code.
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime. |