I just started using Grafana and I am new to SQL as well. I posted this on Grafana community as well, but got no response yet. I set up a simple dashboard with timescaleDB for grafana and the time data was added in the Postgres database as "timestamp without timezone" (e.g:- in the format of '2020-04-27 22:38:36' etc.) In the dashboard, data does not get displayed for the current time while the DB being updated/data does not get displayed for the actual time data was written to the database but displayed with a time shift, when actual data was written at 11.mm.ss they are displayed for 17.mm.ss on the graph. (as here - dashboard picture) (below is the query I make to get the output result shown in the image (I have only written data to the database for an interval of time))
SELECT
"time" AS "time",
score
FROM scoredata
WHERE
"time" BETWEEN '2020-04-27T11:20:35.925Z' AND '2020-04-27T12:20:35.925Z'
ORDER BY 1
I have tried changing the timezone from the dashboard setting as well. But gave no change to the result.
Officially the time column must be in UTC time to be diplayed correct. If this is not the case, you can convert it. I have a PostgreSQL database with local time. To use it correctly in Grafana, I use
$__timeGroupAlias(time at TIME zone 'Europe/Berlin' at TIME zone 'UTC',$__interval,0),
with time as the name of the time column. In the time filter the same has to be done
WHERE
$__timeFilter(time at TIME zone 'Europe/Berlin' at TIME zone 'UTC')
Credits to How to convert local time to UTC?
I got the answer from the Grafana community page. The data needed to be stored in UTC in the database. Grafana will convert them to the local time.
Related
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
Date string should not be converted to local time zone. We want to show the user the date in which record is created. Due to timezone changes we have observed that date is changing.
In web we are removing the time zone so that we we are able to show the date as is.
When we get data from server we are not getting the time zone (Its GMT time). But after saving to jsonstore its getting converted to local time zone and due to that date is getting changed in some cases.
Data received from server - "2019-06-13T00:00:00-05:00"
Data received from json store - "2019-06-13T10:30:00+05:30"
Expected result - "2019-06-13T00:00:00-05:00"
JSONStore stores data as, well, JSON. JSON doesn't have a Date format while JavaScript objects do.
So, when you're writing to the JSONStore, you should convert it to a suitable format that you want - either String or time since epoch. If you convert to String, you can read it out from JSONStore as-is, but the drawback is that you cannot do arithmetic operations on the date without making another conversion.
If you store the time since epoch, you will have to convert it to the desired time zone and then display to your users.
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.
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.