CREATE TABLE DIALOGUE_TABLE(EXPIRE_TIME TIMESTAMP);
Following code snippet is inside stored proc :
PO_EXPIRETIME :- OUT PARAM of procedure a varchar2
SELECT TO_CHAR(SYS_EXTRACT_UTC(EXPIRE_TIME))
INTO PO_EXPIRETIME
FROM DIALOGUE_TABLE;
When I run Stored Proc from server using EXEC and print PO_EXPIRETIME timestamp is proper with UTC format.
But when I call stored procedure from OCCI and client the timestamp recieved is not same but that is the actual timestamp in table not UTC formatted.
Maybe something I am missing but what I don't know?
Is there something in client side I need to do?
If the column is declared as a TIMESTAMP and not, say, a TIMESTAMP WITH TIME ZONE or TIMESTAMP WITH LOCAL TIME ZONE, the timestamp that is stored in the table will not have a time zone component. As a result, SYS_EXTRACT_UTC will convert the timestamp to UTC using the session time zone which is something that is controlled by the client and may be different on different client machines. I suspect that if you run
SELECT SessionTimeZone
FROM dual;
from your OCCI application and from your SQL*Plus session that you will end up with different results which is causing the strings returned to be different.
If you want the string that is returned to be independent of the client machine, I would tend to suggest storing the time zone in the database column. Is changing the schema definition to use a TIMESTAMP WITH TIME ZONE an option? Barring that, you could ensure that every client machine has the same time zone configured and/or run an explicit ALTER SESSION, i.e.
ALTER SESSION
SET time_zone = '-05:00';
in the stored procedure to ensure that the conversion is always done from a particular time zone.
Related
The execution of following SQL in Oracle:
SELECT TZ_OFFSET('Europe/Brussels') from dual;
returns the value +02:00
Note that this function can be used for any timezone in Olsson notation. It's not about the database server.
I was wondering if there exists a similar function in MS Sql Server where you can ask the offset of a given timezone (in the microsoft timezone notation).
From SQL 2016 onward, and in Azure SQL Database, you can achieve this with:
SELECT DATENAME(tz, SYSDATETIMEOFFSET() AT TIME ZONE 'Romance Standard Time')
-- Output: '+02:00'
Notice the time zone names are Windows time zone identifiers, not the IANA TZ (aka Olson) identifiers. For more on the differences, see the timezone tag wiki.
If you want to use IANA TZ identifiers, or if you are using an older version of SQL Server that doesn't have the AT TIME ZONE function, then you can use my SQL Server Time Zone Support project, with the following:
SELECT DATENAME(tz, Tzdb.SwitchZone(SYSDATETIMEOFFSET(), 'Europe/Brussels'))
-- Output: '+02:00'
Also, note that an offset can only be computed for a time zone at a particular reference point. In my examples, you can see I have chosen the current system time with SYSDATETIMEOFFSET(). (The current time is implicit with Oracle's TZ_OFFSET function.)
I am working with CDC in sql and we have a table lsn_timeMapping and a column inside this table trans_begintime its type as mentioned in sql is datetime. My question is how can i get to know that whether it stores datetime in utc format or server datetime .
HERE is a flow mentioned in msdn
It would appear that the time is stored based upon the server's locale settings(local timezone). Therefore, it will not be UTC unless the server timezone is set to UTC.
Source: https://connect.microsoft.com/SQLServer/feedback/details/533689/store-utc-in-lsn-time-mapping
........
Where
(microsdb.MENU_ITEM_DETAIL.CheckDetailID = microsdb.CHECK_DETAIL.CheckDetailID Or
microsdb.DISCOUNT_DETAIL.CheckDetailID = microsdb.CHECK_DETAIL.CheckDetailID) And
microsdb.CHECKS.CheckOpen = CONVERT(CHAR(23), CURRENT_TIMESTAMP, 25)
**Return no result.
Field Data Type
microsdb.CHECKS.CheckOpen (datetime, not null)
CheckOpen 2013-04-08 06:29:26.000
I wondered why my CheckOpen time always 8 hours early than my server time.
Please advise.
Thanks
More than likely, when you stored data into the CheckOpen column of your CHECKS table you parsed it (or read it) directly from a client machine or client interface using their time-zone of US/Pacific.
Later, when you read CURRENT_TIME from your DB server you got the system time for that machine in UTC (since the machine was setup to use UTC by your server admin).
So, the two times are 8 hours off. UTC (GMT) is 8 hours ahead of US/Pacific.
Generally, if a client machine gives you data, you need to parse it, validate it, and sometimes translate it to valid server values or be aware when it's stored that it's only a "client" value. For date/time values, either convert to UTC or be sure to store the "offset" with the stored time. (actually it can be good to store offset even after converting to UTC)
In SQL Server I would like to create a table to save time of an event, and would like to convert it into the timezone of the users choice for display purposes. Let us say that If there was an event that happens in London at 1:00 PM GMT, that would be 8:00 am US EST.
Given This example I would like to create a frame work,
where a user would have an ability to save the event and time (Giving the time zone of the event)
Read Those events, with the time displayed in the time zone of his liking (US EST)
How do I accomplish this in SQL Server.
In SQL Server 2008, use the DATETIMEOFFSET data type which is a DATETIME plus a timezone offset included.
SELECT CAST('2010-11-23 16:35:29+09:00' AS datetimeoffset)
would be Nov 23, 2010, 4:35pm in a +9 hour (from GMT) timezone.
SQL Server 2008 also contains functions and SQL commands to convert DATETIMEOFFSET values from one timezone to another:
SELECT
SWITCHOFFSET(CAST('2010-11-23 16:35:29+09:00' AS datetimeoffset), '+01:00')
would result in:
2010-11-23 08:35:29.0000000 +01:00
Same time, different timezone (+1 hour from GMT)
When you save the data, save the GMT, not the local time for the user (in c# this is DateTime.UtcNow)
In your application logic, record the user's timezone, and translate the GMT time to the user's local time using the timezone offset, at runtime.
The way I've solved a similar problem is to do the following:
The table design is to only store GMT time.
All input goes through a stored proc that requires an input of a timezone offset.
The data request is to a Table-Valued Function, with an input for the timezone offset.
I'm using an Oracle DB and I'm trying to fetch data from its tables using PHP. One of the tables contains a date column which behaves strange to me.
When I open the table in my DB client (I'm using Navicat Lite) I see dates like "2007-11-29 10:15:42" but when I retrieve them with PHP and display the date it says "29-NOV-07". I use a simple SQL query and standard PHP functions (oci_parse, oci_execute, oci_fetch_array).
Why is the value from the DB converted to this (useless) format? How can I get the date just like it is stored in the DB? Thanks for your tips!
Oracle DATE datatype is a point in time, it has no format attached. When you transform a date to a string (to display if for example), the format applied to the date will be dependent upon your session parameters (implicit conversion). From what I remember of PHP, the retrieval functions will convert the date to a string automatically, using the NLS_DATE_FORMAT session parameter.
Either:
change the NLS_DATE_FORMAT beforehand with:
ALTER SESSION SET NLS_DATE_FORMAT='yyyy-mm-dd hh24:mi:ss'
or, if you want to specify another format in your query, you should explicitely ask for it:
SELECT to_char(my_date, 'yyyy-mm-dd hh24:mi:ss') ...
Update
Thanks to ThinkJet for the link to the PHP documentation:
DATE columns are returned as strings formatted to the current date format. The default format can be changed with Oracle environment variables such as NLS_LANG or by a previously executed ALTER SESSION SET NLS_DATE_FORMAT command.