This question already has answers here:
How to handle Day Light Saving in Oracle database
(4 answers)
Closed 2 years ago.
I need a bit of help in changing the time zone in the Oracle cloud infrastructure database. by default it is in UTC I want to change to +5:30 ist
Whether you use the Console or the API, the time zone options you can select from are represented in the named region format, for example, America/Los_Angeles. The Console allows you to select UTC, the time zone detected in your browser (if your browser supports time zone detection), or an alternate time zone.
To specify an alternate time zone (the Select another time zone option), you first select a value in the Region or country field to narrow the list of time zones to select from in the Time zone field. In the America/Los_Angeles example, America is the time region and Los_Angeles is the time zone. The options you see in these two fields roughly correlate with the time zones supported in both the Java.util.TimeZone class and on the Linux operating system. If you do not see the time zone you are looking for, try selecting "Miscellaneous" in the Region and country field.
see here:https://docs.oracle.com/en-us/iaas/Content/Database/References/timezones.htm
Related
Is there any convention to add in a local timezone (whatever the user has set it as) in a database?
For example, like I can do the following for UTC time:
2014-01-01 01:02:03Z
Is there something like the following to mean local time?
2014-01-01 01:02:03L
Or some other suffix where it can either pick up the user's system time or take it from a variable that can be set? For example, something like (for Postgres):
ALTER DATABASE postgres SET timezone TO 'Europe/Berlin';
This has nothing to do with Postgres.
The format you're asking about is ISO 8601. Specifically in that format, the absence of a Z or an offset such as -07:00 or +05:30 is defined as "local time".
So what you are looking for is a string without an offset, such as 2014-01-01T01:02:03.
postgres would use the system timezone, or what you called local, if no timezone is specified. see manual
If no time zone is stated in the input string, then it is assumed to be in the time zone indicated by the system's TimeZone parameter, and is converted to UTC using the offset for the timezone zone.
...
Conversions between timestamp without time zone and timestamp with time zone normally assume that the timestamp without time zone value should be taken or given as timezone local time.
Your concept is flawed for a couple of reasons:
A user in Germany connects to a Web server in England that connects to a database server is America. What constitutes local?
More to the point Postgres does not store the time zone in with time zone fields. So you will not recover the entered time zone on data retrieval.
If you are dealing with multiple time zones then the field you need to use is timestamp with time zone. This will rotate entered timestamp values to UTC for storage. You now have a fixed point in time that you can rotate to whatever 'local' time you want on retrieval.
Just treat the undecorated time as a timestamp with time zone:
richard=> SET timezone='Europe/London';
SET
richard=> SELECT '2022-08-27 21:42:22.25891'::timestamptz;
timestamptz
------------------------------
2022-08-27 21:42:22.25891+01
(1 row)
richard=> SET timezone='Europe/Paris';
SET
richard=> SELECT '2022-08-27 21:42:22.25891'::timestamptz;
timestamptz
------------------------------
2022-08-27 21:42:22.25891+02
(1 row)
select current_time at time zone 'GMT-2'
returns
"11:54:40.22045+02"
but correct local time in Windows is one hour different:
12:54
How to get correct local time ?
Using
"PostgreSQL 9.6.0, compiled by Visual C++ build 1800, 32-bit"
with standard postgresql.conf file in Windows 10
Same issue occurs also in ealier Postgres and in earlier windows.
Server time in Windows is correct.
Daylight saving time was changed by one hour a week ago.
Maybe postgres didnt recognized it.
Don't use time with time zone, it is a useless data type.
See the documentation:
The type time with time zone is defined by the SQL standard, but the
definition exhibits properties which lead to questionable usefulness.
In most cases, a combination of date, time, timestamp without time zone,
and timestamp with time zone should provide a complete range of date/time
functionality required by any application.
Use localtime to get the current time at your current session time zone (defined by the TimeZone parameter).
Our application uses CURRENT_TIMESTAMP to store an event when a user submitted the data. This is stored in a TIMESTAMP WITH LOCAL TIME ZONE type column. Our servers are in PST timezone, but I want to see what time one of our users in Australia submitted the data in Australian time? I am confused how to do this properly? When I query the database right now this column seems to show the date the row was submitted but in PST time for every row.
Something like this:
SELECT
datetime_submitted -- I want this to display the time this value was created in Australian time not PST
FROM my_table
WHERE user = 'AUSTRALIAN';
Use the AT TIME ZONE clause:
select systimestamp as server_timestamp,
systimestamp at time zone 'Australia/Sydney' as australia_timestamp
from dual;
SERVER_TIMESTAMP AUSTRALIA_TIMESTAMP
-------------------------------------- --------------------------------------
12-AUG-16 04.12.23.789000000 PM -05:00 13-AUG-16 07.12.23.789000000 AM AUSTRALIA/SYDNEY
Right now it is 4:12:23 PM on 12 August 2016 at my location (Central time, US); it is already tomorrow in Australia, as you can see from the example. (Reminds me the joke - don't worry about the end of the world coming today, it's already tomorrow in Australia!)
If you want to just look at the time in the user's time zone you can set the session to whatever time zone the user is located in then when you select the times it should give it back to you in that time zone as if you were that user.
% setenv ORA_SDTZ '+09:30'
or
ALTER SESSION SET TIME_ZONE='+9:30';
Reference for more details: https://docs.oracle.com/cd/E11882_01/server.112/e10729/ch4datetime.htm#NLSPG263
Updated
If you only want one column displayed in a different time zone then you can convert it.
To convert the timezone just in the query you can just use CAST(date_field AS TIMESTAMP) AT TIME ZONE 'US/Eastern' AS time_name on the column you want to change.
Reference for more details: https://docs.oracle.com/cd/B19306_01/server.102/b14225/ch4datetime.htm#i1007699
First, your application need to receive exact date time with user local timezone. For example, if you have typical web application with frontend, backend and database, then your frontend need to send exact date time with local user timezone (for example "2016-08-08 03:00:00CST") to your backend. Backend need to save this in a table as-is keeping date, time, timezone information received from frontend. Oracle needs to store date, time and timezone into database as-is so datetime_submitted column should have information about time zone. Suitable data type for it will be TIMESTAMP WITH TIME ZONE, as described here: https://docs.oracle.com/cd/B28359_01/server.111/b28318/datatype.htm#CDEGDFFE
Maybe you did not fully understand data type TIMESTAMP WITH LOCAL TIME ZONE. Data type TIMESTAMP WITH LOCAL TIME ZONE shows time values always and only in current user session time zone.
When you work with time zones then often you get an advise like: "Store all times in UTC time and convert displayed value at application layer." That is exactly how TIMESTAMP WITH LOCAL TIME ZONE works. The mayor difference is, times are not stored at UTC but at DBTIMEZONE (unless you set DBTIMEZONE = UTC, of course). Hence you cannot modify DBTIMEZONE setting once you have any data in a TIMESTAMP WITH LOCAL TIME ZONE column.
You get an error if you try for example TO_CHAR(datetime_submitted, 'hh24:mi:ss TZR'), because time zone region is by definition always your current user session time zone.
The database does not know the time zone of your users in Australia, because all stored times where converted to PST time zone (well, most likely to -08:00 but skip the details here).
If you like to see the values in a different time zone then you have to change your current user session time zone. Typically you do this by ALTER SESSION SET TIME_ZONE=... or by environment variable, resp. Registry setting ORA_SDTZ.
Another solution is to cast to TIMESTAMP WITH TIME ZONE or TIMESTAMP data type.
I have a TIMESTAMP field in an hsqldb table that I want to set to "2015-02-11 16:02:01.488 America/Los_Angeles", but the insert fails even if I set the column to TIMESTAMP WITH TIMEZONE, the reason being hsqldb seems to support '2008-08-08 20:08:08-8:00' format but not spelled out like America/Los_Angeles. Is there way to make the insert accept America/Los_Angeles type zones ?
Sorry, but hsqldb doesn't support working with IANA/Olson time zones directly. You are correct that TIMESTAMP WITH TIMEZONE only supports a time zone offset. You can review the hsqldb docs for confirmation.
Many databases do not support named time zone. Oracle and Postgres support them, but most others do not.
Consider also that while a named time zone can usually determine the offset, there are still cases of ambiguity around the fall-back daylight saving time transition. In other words, if you had "2015-11-01 01:30:00 America/Los_Angeles", you could not deterministically tell whether it was Pacific Daylight Time (UTC-07:00) or Pacific Standard Time (UTC-08:00). This is why usually just the offset is stored.
The converse is also true though. If you only store "-08:00" then you can't deterministically know that it came from "America/Los_Angeles".
Here's a general guideline that will help:
If the local time is unimportant, then just store a TIMESTAMP based on UTC.
If the local time is important, but the value will never be modified, then store a TIMESTAMP WITH TIMEZONE, using the local time and it's associated time zone offset.
If the local time is important AND the value can be modified, then store a TIMESTAMP WITH TIMEZONE in one column, and the time zone name (ie. "America/Los_Angeles") in a second VARCHAR column, or elsewhere in your database. During an edit operation, use the time zone name to calculate the offset of the new value. It might be the same, or it may be different.
See also DateTime vs DateTimeOffset, which presents a similar argument for .Net and/or SQL Server.
Q1: I want to convert a unix timestamp (INT) to monetdb timestamp ('YYYY-MM-DD HH:MM:SS') format
but it is giving me the GMT time not my actual time.
When I do
select (epoch(cast(current_timestamp as timestamp))-epoch(timestamp '2013-04-25 11:49:00'))
where 2013-04-25 11:49:00 is my systems current time it gives the same difference
I tried using
set time zone interval '05:30' HOUR TO MINUTE;
but it did not change the result
How can I solve this problem??
Example Problem:
I wanted to convert unix timestamp 1366869289 which should be around "2013-04-25 11:25:00" but monetdb gives "2013-04-25 05:55:00"
Knowing nothing about MonetDB, but a lot about timezones, I decided to look in their documentation to see what kind of datatypes are supported and how conversions are handled.
I found this page on Temporal data types. Based on that, I can conclude that a timestamp in MonetDB is always intended to reference UTC/GMT time - which is consistent with other systems.
In order to get a value that is for a particular time zone, they offer the following example:
SET TIME ZONE INTERVAL '1' HOUR TO MINUTE
I assume this means to set the database to offset all times by 1 hour, effectively placing the values all in UTC+01:00, such as is the offset for British Summer Time.
The page also goes on to point out the problems that can arise with using just and offset to adjust time values (see TimeZone != Offset in the TimeZone tag wiki). It also offers a list of various named time zones. But it does not show how to set a time zone to one of the named values. Also, their list appears to be proprietary, and incomplete. While at first glance they appear to have similarities to the IANA/Olson time zone database - the identifiers they specify are not valid TZDB names.
There are some other functions listed on this page, without much explanation. One that looks promising for your needs is LOCALTIMESTAMP. Perhaps this will take the local time zone into account, which appears to be what you were looking for.
I could not find any additional details specific to MonetDB date/time/timezone handling. The documentation appears to be fairly incomplete. You might want to reach out to their mailing list.