Date different

[P.Hill]

Just because I am not persuaded by your arguments does not necessarily
mean I did not read or understand them.

Obviously, Calendar is not a complete replacement for Date. It is too
fat. It is designed for doing date calculation, not just transporting
a date/time as an object which is the new function of Date.

Sounds like we do nearly agree, despite your complaints and
code suggesting the contrary. Oh and being fat comes (mostly) with
dealing with amazing kludgy world of timezones, daylight savings
and our hodgepodge of a calendar.

I find your patronising unusually inappropriate.

Roedy, I've have been wading through your Date Gotchas and articles
since you wrote them. There still seem to be way too many complaints
about the API and trivialities like the sad name of the class and not
enough a discussion of dates vs. datetimes vs. timestamps, for those who
actually need to understand and use dates AND times.

I helped persuade Sun they needed a replacement..

Which of course they had to do through deprecation for compatibility
reasons, so complaining about a bad choice of name which had to be
retained seems like a waste of bandwidth.

Speaking of conflagulating dates vs times and datetimes:

I'm the guy who wrote BigDate, a Date replacement

Of course BigDate is a date object while java.util.Date contains
date and time, so one doesn't replace the other, except in
a common but useful subset of uses for dates only, which apparently
includes some use in:

[...] satellite communication networks.

Congratulations on that (Yes, I'm serious).

But for your readers you might want to update your bigdate page
http://mindprod.com/jgloss/bigdate.html

"BigDate differs from Sun's Date in that it handles dates prior to 1970"
hasn't been the case for going on half a decade now. I believe it all
happened when JDK 1.1 came out.

"unlike Sun's Date which uses 00=Jan" -- no actually Calendar uses 0=
Calendar.JANUARY, which I believe is a bit like BigDates days of the
week which has Sunday=0. The uses of value by Date is mostly mute since
all of those parts of the API are deprecated.

Since I haven't used BigDate myself I hadn't visited this page
in a very long time, so I hadn't noticed until now the above two
old typos. Apologies for not pointing it out sooner, since I've often
been found trying to improve information and uses of Date, Calendar etc.
on this list.

peace be with you,
-Paul

p.s. glad to see you're back on your feet and working again.

 

[steve]

I thought JDBC was supposed to bypass that nonsense.

well jdbc only return what the database tells it.

This is what oracle have to say on the matter.


What is going on with DATE and TIMESTAMP?
This section is on simple data types.
Prior to 9.2, the Oracle JDBC drivers mapped the DATE SQL type to
java.sql.Timestamp. This made a certain amount of sense because the Oracle
DATE SQL type contains both date and time information as does
java.sql.Timestamp. The more obvious mapping to java.sql.Date was somewhat
problematic as java.sql.Date does not include time information. It was also
the case that the RDBMS did not support the TIMESTAMP SQL type, so there was
no problem with mapping DATE to Timestamp.
In 9.2 TIMESTAMP support was added to the RDBMS. The difference between DATE
and TIMESTAMP is that TIMESTAMP includes nanoseconds and DATE does not. So,
beginning in 9.2, DATE is mapped to Date and TIMESTAMP is mapped to
Timestamp. Unfortunately if you were relying on DATE values to contain time
information, there is a problem.
There are several ways to address this problem:
€ Alter your tables to use TIMESTAMP instead of DATE. This is probably
rarely possible, but it is the best solution when it is.
€ Alter your application to use defineColumnType to define the columns as
TIMESTAMP rather than DATE. There are problems with this because you really
don't want to use defineColumnType unless you have to (see What is
defineColumnType and when should I use it?).
€ Alter you application to use getTimestamp rather than getObject. This i
s a good solution when possible, however many applications contain generic
code that relies on getObject, so it isn't always possible.
€ Set the V8Compatibility connection property. This tells the JDBC driver
s to use the old mapping rather than the new one. You can set this flag
either as a connection property or a system property. You set the connection
property by adding it to the java.util.Properties object passed to
DriverManager.getConnection or to OracleDataSource.setConnectionProperties.
You set the system property by including a -D option in your java command
line.
€ java -Doracle.jdbc.V8Compatibility="true" MyApp

which basically means that if you coded for date returning timestanp it
worked.
the "alter your application" solution is just stupid, as you now have to
produce either table specific java code or check the metadata and filter
out the dates.

changing you table to timestamp , means exporting the data , and scrapping
off the old table , rebuilding it , and then re-importing the data.


their solution of mapping date to date , is still wrong, because date still
returns time information , which is lost in the translation to date.

to make it more complex, on the return trip back to the database, if you use
stored sql procedures to write the data back to the database, they are also
now broken.
because they are expecting a "Date", but now oracle has returned a
"Timestamp"

 

[steve]

It could either be your JTables job to override the cell renderer
which would then use a a SimpleDateFormat to generate an appropriate
String (without milliseconds) given a Date, or it may be your
middle-tier object that converts any random date, datetime, timestamp
etc from the database into some other appropriate business object.

[...]

i tracked it down!!
oracle changed the default types returned for their newest oracle drivers,
so
getobject() actually returns the WRONG type.
you now have to SPECIFICALLY get the data with 'rset.getTimestamp', which
now
means the code has to compare the metadata for every column.

At 1st blush that seems like a violation of the ResultSet API contract.
What is the inheritance tree of this new object which it would
give you by default if you load up for an array of objects?

-Paul

wrong information in you array of objects, that's what you get.

Their mapping of Date to Date, is just crass and lacks thought.
it should be mapped not based on the name, but on the data it returns,
not doing that results in loss of information.

Steve

 

[P.Hill]

steve wrote:
[...]

This is what oracle have to say on the matter. [...]
Prior to 9.2, the Oracle JDBC drivers mapped the DATE SQL type to
java.sql.Timestamp.

[...]
The difference between DATE

and TIMESTAMP is that TIMESTAMP includes nanoseconds and DATE does not. So,
beginning in 9.2, DATE is mapped to Date and TIMESTAMP is mapped to
Timestamp. Unfortunately if you were relying on DATE values to contain time
information, there is a problem.

Sh*t, that is crazy. I think I would go with the V8Compatibility="true".

AFAIK, This is nothing in the JDBC spec that says there is a two-way
unique mapping between jdbc types and DBMS types. They could return
java.sql.Timestamp for both a DATE and a TIMESTAMP. Apparently
a DATE in Oracle (not unlike the misnomer in of java.util.Date class)
contains date and time information, but is now being interpreted as just
containing date when translated in the driver. I am reading that right
am I not? Oracle DATE is a date and a time? You seem to agree in your
post.

€ Alter your tables to use TIMESTAMP instead of DATE. This is probably
rarely possible, but it is the best solution when it is.

Why is this so rarely possible?

€ Set the V8Compatibility connection property. This tells the JDBC driver
s to use the old mapping rather than the new one. You can set this flag
either as a connection property or a system property. You set the connection
property by adding it to the java.util.Properties object passed to
DriverManager.getConnection or to OracleDataSource.setConnectionProperties.
You set the system property by including a -D option in your java command
line.
€ java -Doracle.jdbc.V8Compatibility="true" MyApp

Note you can also define a system property in the application startup
as long as it happens somewhere before JDBC tries to connect.

changing your table to timestamp , means exporting the data , and scrapping
off the old table , rebuilding it , and then re-importing the data.

Is that so hard? That would be my solution in things I've done.

their solution of mapping date to date , is still wrong, because date still
returns time information, which is lost in the translation to date.

Yes, I have to agree.

to make it more complex, on the return trip back to the database, if you use
stored sql procedures to write the data back to the database, they are also
now broken.
because they are expecting a "Date", but now oracle has returned a
"Timestamp"

But I believe Oracle is required by the JDBC spec to accept a
java.util.Date when setting a column, and convert appropriately, but
this might require some more specific code in the app. My experience
has been that creating the right object is often possible; YMMV.

Is Oracle trying to get away from people using their DATE as a datetime
outside of its use in JDBC? This might explain (but not excuse) their
choice of using java.sql.Date.

I wonder if
public Object getObject(int i,
Map map)
http://java.sun.com/j2se/1.4.2/docs/api/java/sql/ResultSet.html#getObject(int, java.util.Map)
could be used to help here. I have never used it myself.

-Paul



-Paul

 

[Roedy Green]

Roedy, I've have been wading through your Date Gotchas and articles
since you wrote them. There still seem to be way too many complaints
about the API and trivialities like the sad name of the class and not
enough a discussion of dates vs. datetimes vs. timestamps, for those who
actually need to understand and use dates AND times.

The fundamental problem is they did not understand that Dates are
animals in their own right. Much of the time you want pure date. When
is Christmas has nothing to do with timezones, daylight savings, AM/PM
or much of that other eccentric weirdness we humans have tacked onto
time.

When I bitch about a misnamed method, class etc. I am doing three
things:

1. publicly flogging the incompetent programmer and those who OKed his
work.

2. trying to discourage Sun and others from being similarly sloppy
with names on other projects. Accurate naming is my hobbyhorse
see http://mindprod.com/jgloss/unmainnaming.html
http://mindprod.com/jgloss/naming.html.

3. warning people that methods don't do what you would intuitively
think they should. You have been burned. You read the JavaDoc
carefully. Most new folk think of a function they would like, then
look for a method with a name that roughly describes it, and blithely
presume that is what it implements. I am out to protect the newbie.

 

[Nigel Wade]

The fundamental problem is they did not understand that Dates are
animals in their own right. Much of the time you want pure date. When
is Christmas has nothing to do with timezones, daylight savings, AM/PM
or much of that other eccentric weirdness we humans have tacked onto
time.

Timezone is vital in determining *where* it is Christmas. You might
think it's still Christmas Eve, but they've already eaten their
Christmas dinner in Australia.

A date in isolation is pretty meaningless. It is a specific 24hr period
in time. Without timezone information you can't unambiguously state
which particular 24hr period it refers to. Was it the 24hrs of
Christmas Day in Toronto, or the different 24hrs of Christmas Day in
Moscow?

 

[Roedy Green]

Timezone is vital in determining *where* it is Christmas. You might
think it's still Christmas Eve, but they've already eaten their
Christmas dinner in Australia.

It depends on your question. If you are trying to print a calendar to
sell in the mall, timezone is irrelevant. If you are talking about
when someone's birthday is, or what day of the month the mortgage
comes out, or when the next JUG meeting is, likewise timezone is
irrelevant. Forcing date-only code to deal with that complication
introduces bugs and makes simple calendar problems into mountains..

As soon as you throw a time of day in to the mix, or talk about he
precise instant a day begins, then Timezones and daylight saving
become relevant.

The error Sun made it my opinion was not having a simple timeless date
like BigDate for date-only problems, then extending it with time.

There also needs three stripped down carrier classes for persistent
storage:
pure date
UTC time
UTC time + timezone.

 

[Roedy Green]

Their mapping of Date to Date, is just crass and lacks thought.
it should be mapped not based on the name, but on the data it returns,
not doing that results in loss of information.

Maybe the next layer of Chinese menu in JDBC will let you define your
own custom conversion functions both ways between Java classes and
primitives and what the database offers to help you get past goofy
stuff like this.

 

[Nigel Wade]

It depends on your question. If you are trying to print a calendar to
sell in the mall, timezone is irrelevant. If you are talking about
when someone's birthday is, or what day of the month the mortgage
comes out, or when the next JUG meeting is, likewise timezone is
irrelevant.
Forcing date-only code to deal with that complication
introduces bugs and makes simple calendar problems into mountains..

I don't agree that there is any such thing as date-only code. Pretending that
there is, is where the bugs come from. You can only safely ignore time and
timezones if you understand them, and understand when they can be ignored.

As soon as you throw a time of day in to the mix, or talk about he
precise instant a day begins, then Timezones and daylight saving
become relevant.

The error Sun made it my opinion was not having a simple timeless date
like BigDate for date-only problems, then extending it with time.

There also needs three stripped down carrier classes for persistent
storage:
pure date
UTC time
UTC time + timezone.

You only need one, UTC. That contains all the necessary information to indicate
a specific instance in time. Timezone is only needed as a viewing model to
convert the instance in time into your own personal reference frame. "Pure
date" is ambiguous and shouldn't be used for recording anything important. Date
plus timezone has some meaning, so that might be useful in some circumstances.

 

[Roedy Green]

I don't agree that there is any such thing as date-only code. Pretending that
there is, is where the bugs come from. You can only safely ignore time and
timezones if you understand them, and understand when they can be ignored.

Explain how the question "What day of the week will your 90th birthday
come on" has anything to do with timezones. They could all totally
change and the answer would be the same.

Explain how the question "On what day of next month will the PC User
group meet if they always meet on the third Thursday of each month?"
has anything to do with timezones.

 

[Nigel Wade]

Explain how the question "What day of the week will your 90th birthday
come on" has anything to do with timezones. They could all totally
change and the answer would be the same.

Explain how the question "On what day of next month will the PC User
group meet if they always meet on the third Thursday of each month?"
has anything to do with timezones.

I've already explained my reasoning. There are occasions where you can safely
ignore timezone, but only when you understand them. To do so without
understanding them can, and almost surely will, lead serious bugs.

There are plenty of examples in posts to these newsgroups which show how false
assumptions regarding ignoring timezones leads to errors.

 

[Roedy Green]

I've already explained my reasoning. There are occasions where you can safely
ignore timezone, but only when you understand them. To do so without
understanding them can, and almost surely will, lead serious bugs.

There are plenty of examples in posts to these newsgroups which show how false
assumptions regarding ignoring timezones leads to errors.

That's what I have been saying. Java's official classes MAKE you be
timezone aware even when it is irrelevant. They add a
timezone/daylight saving complication that is not inherently part of
many problems.

You can't use Java's official tools without fretting over timezones.
It is often an unnecessary complication.

Too see what I mean see http://mindprod.com/jgloss/calendar.html
and see how some problems are so much more simply solved with the
BigDate class which uses a pure date. There are dozens of example
problems that come with the source for it.

 

[Andrew]

I agree with Roedy, as a newbie to Java I found this complication a
complete waste of time. If I just want a date to store it as a date
thats all then that is what I should be able to to.

Of course there are situations where one needs to take into account
timezones but in my experience in business, the manager wants to know
when a transaction occurred, this time is always the local time it
occurred where it occurred nothing else. I have been fortunate enough
that I have never encountered a request or wish to have it shown in any
other way.

Having said that there are others that have and before anyone says
anything, I deal with a minimum of 3 timezones all the time.