Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>The class <code>java.sql.Date</code> corresponds to SQL DATE, which does not store time or timezone information. The way this is accomplished is by 'normalizing' the date, like the <a href="http://docs.oracle.com/javase/6/docs/api/java/sql/Date.html" rel="nofollow">javadoc</a> puts it:</p> <blockquote> <p>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.</p> </blockquote> <p>This means that when you work in UTC+1 and ask the database for a DATE a compliant implementation does exactly what you've observed: return a java.sql.Date with a milliseconds value that corresponds to the date in question <em>at 00:00:00 UTC+1</em> independently of how the data got to the database in the first place.</p> <p>Database drivers may allow changing this behaviour through options if it's not what you want.</p> <p>On the other hand, when you pass a <code>java.sql.Date</code> to the database, the driver will use the default time zone to separate the date and time components from the millisecond value. If you use <code>0</code> and you're in UTC+X, the date will be 1970-01-01 for X>=0 and 1969-12-31 for X&lt;0.</p> <hr> <p>Sidenote: It's odd to see that the documentation for the <a href="http://docs.oracle.com/javase/6/docs/api/java/sql/Date.html" rel="nofollow"><code>Date(long)</code> constructor</a> differs from the implementation. The javadoc says this:</p> <blockquote> <p>If the given milliseconds value contains time information, the driver will set the time components to the time in the default time zone (the time zone of the Java virtual machine running the application) that corresponds to zero GMT.</p> </blockquote> <p>However what is actually implemented in OpenJDK is this:</p> <pre><code>public Date(long date) { // If the millisecond date value contains time info, mask it out. super(date); } </code></pre> <p>Apparently this "masking out" is not implemented. Just as well because the specified behaviour is not well specified, e.g. should 1970-01-01 00:00:00 GMT-6 = 1970-01-01 06:00:00 GMT be mapped to 1970-01-01 00:00:00 GMT = 1969-12-31 18:00:00 GMT-6, or to 1970-01-01 18:00:00 GMT-6?</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload