[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [sdo] [SDO-63]: Date conversions confusing
Frank Budinsky [07/Dec/06 04:36 PM]
Hi Radu,
I haven't given this much thought myself, but I asked the guy working on
data conversion in the Tuscany implementation (Brian Murray) for his
thoughts, see below.
Frank.
> 1. The way the spec describes (in chapter 8.1.3) conversions to/from
Day, Month, Year, MonthDay, ...
Both of the listed concerns are correct. Each of the formats is listed
on page 138 (Chapter 16) as being capable of converting to a Date. Most
of these (all but Duration, DateTime, and Date) will have incomplete
information and assumptions must be made (I'll address the issue of
assumptions in response to question 3, which deals directly with the
topic). It is no different than if you'd provided a Month and attempted
toDay (which is understandably not permitted). However, note that the
following is permitted: Month -> toDate -> toTime.
This sequence is not something a developer would knowingly perform,
however it's easy to imagine a situation in which it is unwittingly
performed.
I think this speaks very well to the problematic nature of using the
Date class. If we allow conversion to Date from all the formats (the
current spec), then there is no way to track that assumptions were made
- let alone the affected 'fields' (fields don't really exist in a Date,
which is stored as a long value). Calendar, however, has internal
mechanisms for tracking whether each field was set. Using these tools,
we could insure that the second transition in Month -> toCalendar ->
toTime would throw an Exception.
His second bullet is an insight I had not considered and is problematic.
> 2. Converting Duration values to Date makes no sense; in addition
to ...
Providing the DataHelper.toDate() with a String of "P20M" currently
results in a null return value.
In the SDO implementation, the Duration is converted to a Date using a
SimpleDateFormat. Fields not present in the Duration are defaulted to
their corresponding values in the epoch. In this way, allowing the
conversion between Duration and Date sidesteps some explicit (and
well-considered) Java requirements when dealing with Duration. For
example, there is a Duration.getTimeInMillis() method, but you must
provide a startInstant to that method. This is a recognition of the fact
that the P2M Durations (July-August), (January-February 2006), and
(January-February 2008) are each quite different.
I absolutely agree that it would be ideal if conversions between
Duration and Date (or Calendar for that matter) were not permitted.
> 3. Assuming that conversions between those are necessary ...
He is suggesting using the epoch as a default startInstant. In this way
- P2006Y11M21D would convert to Dec 22 00:00:00 3976. If such a default
startInstant did exist, it does seem to me that conversion from Date to
Duration would be possible (if we allow it) and simply mean the Duration
between the Date and the startInstant. (Again, I would vote against both
Duration->Date and Date->Duration.)
This does bring up the question of assumptions though. I see three
possibilities:
1. Assume well-defined default values (with the epoch often suggested as
providing the values).
2. Assume default values obtained from the current timestamp.
3. Prevent visibility to the fields which have been assumed.
Here are the issues with each:
1. You enter into some very unusual daylight savings time issues.
Particularly in the year 1970 - which the epoch would place you in when
no year is provided. (1970 I believe is during the period when England
was on Double Summer Time.)
2. The default values would be different every time you ran it.
3. The conversions would have to be through Calendar rather than Date.
This would be a change from the current specification. (In particular
Chapter 16.)
Thank you,
Brian Murray
Radu Preotiuc [07/Dec/06 06:50 PM]
One specific point regarding Duration conversion from/to Date. Even if
we choose a given reference Date, we still have the problem of durations
like 61 days; once you add it to a reference date, you no longer know if
the duration was 61 days or 2 months, even if you know the reference
date.
And one more general thought about a parallel between a "lossy"
conversion from long to byte and a conversion from Month to Date. In the
first case, even though the conversion is "lossy", there are long values
that will convert to byte without loss of information and all byte
values will convert to long without loss of information. So, in another
words, the value spaces of long and byte overlap. In the Month to Date
case, there is no Month that also represents a Date and no Date that
also represents a Month. So conceptually, the value spaces are disjoint.
So I guess this would be one more argument against having the conversion
at all.
Ulf von Mersewsky [15/Jun/07 10:17 PM]
As I described in SDO-95 I agree with Radu that it is not a good idea to
convert a duration to a date in the way it's described in the spec.
In my eyes a java.util.Date gives you a certain amount of milliseconds.
It's up to your environment to define timezone, daylight saving time
etc. Another point is the current date as basis of the date conversion.
That means that every conversion would produce a different result. Here
reference date would help. I would prefer January 1st 1970 or more
technically spoken new Date(0); In this case a conversion of a duration
into a date would include a "normalization" of the duration to the
equivalent amount of milliseconds starting from January 1st 1970.
While thinking about all these conversions I'm not sure for what types
we should provide them. A conversion is possible where all information
regarding time and/or date are given. (Date, DateTime, Time,
YearMonthDay)
Radu Preotiuc [07/Jul/07 03:21 AM]
Here is the proposal for Date types conversions. In addition to
replacing the current chapters 8.1.1-8.1.3 with the new text, we would
need to change the titles only for current chapters 8.1.4 and 8.1.5
Replace
8.1.4 DataObject.getString() and setString() on a property of type Bytes
with
8.1.8 DataObject.getString() on a property of type Bytes and
DataObject.setBytes() on a property of type String
and
8.1.5 DataObject.getBytes() and setBytes() on a property of type String
with
8.1.9 DataObject.getBytes() on a property of type String and
DataObject.setString() on a property of type Bytes
Blaise Doughan [09/Jul/07 07:38 PM]
There are two main approaches to time zone:
* Assume GMT/UTC (as proposed in the attached doc)
* Assume VM TimeZone (as done by specs such as JAXB), my
preference.
Our (Oracle) experience:
* Customers prefer using the VM TimeZone.
* Customers wanting to ensure all tools (from multiple vendors)
use the same time zone (for unqualified time information) set
their servers to the GMT/UTC time zone. This ensures that tools
using either of the above options interpret time information the
same.
Things we (Oracle) have done:
* Provided a value-add option to allow the user to specify the
time zone in which conversions will be done. For us this is an
XMLHelper level setting.
* Provided a value-add option to allow the user to specify whether
or not the string representation of time information is time
zone qualified. This is necessary for true interoperability.
Locale and Time Zone:
* The Locale paramter does not imply a Time Zone, it only allows
for region specific date/time seperation characters.
Radu Preotiuc [04/Aug/07 03:26 AM]
>From our (BEA) experience on the other hand, we had some trouble using
the VM timezone because in Java the UTC offset of a timezone depends on
the date in the year and the daylight saving cutoff times, which can
change (and is changing). But of course that goes beyond the rules for
this conversion, so we are fine with using the VM timezone if everyone
agrees. I will ammend the proposal.
As for the Locale issue, you are of course right. I will remove that
sentence from the text.
Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]