[
https://issues.apache.org/jira/browse/DERBY-2235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12523874
]
Ken Johanson commented on DERBY-2235:
-------------------------------------
I believe that until/if timezone storage is supported, the server should treat
it as whatever the default (timezone-less) string representaion of an iso8601.
In otherwords it should store the '2007-01-03 04:13:43.006' value, minus 8
hours, if a timezone-less string ordinarily defaults to GMT. Or is a tz-less
string defaults to the system's tz, i.e if the tz-less string defaults to EDT
and a PDT timezone is entered, the offset from EDT to PDT should be used to
create the value that EDT would use:
1) server runs in EDT (ie INSERT 2007-01-03 04:13:43 = 2007-01-03 09:13:43 GMT)
2) server recieves INSERT '2007-01-03 01:00:00.006.006 -0800', translates to
2007-01-03 04:00:00.006, ie 2007-01-03 09:00:00.006.
It would be argued by some that if a TZ value is present but cannot be stored
an error should be reported, but other users would elect (given config option)
to just have to auto-computed to real time (without tz).
> Server doesnt support timestamps with timezone
> ----------------------------------------------
>
> Key: DERBY-2235
> URL: https://issues.apache.org/jira/browse/DERBY-2235
> Project: Derby
> Issue Type: Improvement
> Components: SQL
> Affects Versions: 10.2.2.0
> Reporter: Ken Johanson
> Priority: Minor
>
> DML with datetime literals having timzone offset data (ISO-8601):
> update tbl set dt1 = '2007-01-03 04:13:43.006 -0800'
> Causes:
> SQLException: The syntax of the string representation of a datetime value is
> incorrect.
> Error: -1 SQLSTATE: 22007
> I believe that even if the storage does not (does it?) support timezone
> storage, the input of a TZ could be normalized (offset applied) to the
> default TZ.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
