You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Yields the following output. Note the Time prefixed items are scanned to type time.Time while the string fields are using oracle TO_CHAR to produce the real time.
{
"CurrentDate": "2023-08-07 10:07:39",
"CurrentTimestamp": "2023-08-07 10:07:39 -05:00",
"Sysdate": "2023-08-07 10:07:39",
"Systimestamp": "2023-08-07 10:07:39 -05:00",
"TimeCurrentDate": "2023-08-07T10:07:39Z",
"TimeCurrentTimestamp": "2023-08-07T15:07:39.24578-05:00",
"TimeSysdate": "2023-08-07T10:07:39Z",
"TimeSystimestamp": "2023-08-07T15:07:39.245776-05:00"
}
Sysdate: Mon Aug 7 10:07:39 UTC 2023
Systimestamp: Mon Aug 7 15:07:39 -05:00 2023
Real Time: Mon Aug 7 10:07:39 CDT 2023
Above we can see
sysdate scanned to time.Time is the correct time, but defaults to wrong zone.
systimestamp scanned to time.Time is the right zone, but the wrong time.
I think the solution is to default to the zone resulting from select to_char(systimestamp,'TZR') from dual; for both date and timestamp oracle types with a connection option being added to use any specific zone as the default and override the above assumption.
The above is the approach used by github.com/godror/godror godror has a whole document on this subject and oracle's poor presumptions at: timezone.md
I'd love to use your instant client free driver, but until it can tell time, I cannot.
I believe this was nearly solved in: #24
I just re-ran my test with v2.7.11 on with go1.20.7.
Given the following
struct
and SQL query:And the following Testing Functions
Yields the following output. Note the
Time
prefixed items are scanned to typetime.Time
while the string fields are using oracleTO_CHAR
to produce the real time.Above we can see
sysdate
scanned totime.Time
is the correct time, but defaults to wrong zone.systimestamp
scanned totime.Time
is the right zone, but the wrong time.I believe the issue resides in v2.7.11 here
I think the solution is to default to the zone resulting from
select to_char(systimestamp,'TZR') from dual;
for bothdate
andtimestamp
oracle types with a connection option being added to use any specific zone as the default and override the above assumption.The above is the approach used by github.com/godror/godror
godror
has a whole document on this subject and oracle's poor presumptions at: timezone.mdI'd love to use your instant client free driver, but until it can tell time, I cannot.
I have a full version of my test ready to run at: https://github.com/RileyRaschke/goora_date_test
The text was updated successfully, but these errors were encountered: