I recently started using Grafana to show data I have in my PostgreSQL Database.
Now I've reached a point where when selecting data and using a certain timestamp field as the "time" field in Grafana, the data that's shown is the dates + timezone difference.
For example:
My data has the timestamp "2020-08-24 12:05:30" and my timezone is UTC+3, but Grafana shows it as "2020-08-24 15:05:30".
Is there any way to simply display the data as it exists in my DB without adding that timezone difference?
Go to the dashboard settings and make sure the timezone is set to UTC or whatever timezone is used by the data.
Changing the timezone wasn't my solution, as it would also shift "now".
I simply added an interval to my query:
TO_TIMESTAMP(DateTime, 'YY-MM-DD HH24-MI-SS') - interval '2 hour' as time
to shift it 2 hours
The way I think it is intended to be used is:
Storing of dateTime values in the database should be in UTC only. (E.g. send a string representation of datetime.datetime.utcnow() to PostreSQL).
If you then select your timezone in Grafana's settings, things should work as expected.
Related
I have a:
Field in my store as date with dateFormat set to 'Y-m-d'
Column in my grid (datecolumn) - format set to 'Y-m-d'
Editor on Column (datefield editor) - format set to 'Y-m-d'
Postgresql Table with a date column (Note, not a timestamp or timestamptz, but date)
I have data that comes into the store from Postgresql like:
{
mydatefield: "2021-07-30"
}
Now, the date do dispay is 100% correct in the grid. Problem comes in when I select a new date, through the datefield editor, let's say
2021-07-31
The moment it saves back to the server it passes:
mydatefield: '2021-07-30T22:00:00.000Z'
and the server saves it wrong as '2021-07-30' and the grid refreshes back to 2021-07-30.
We are on South African Standard Time (+2) Do not know if it something to do with Daylight Saving
So, to recap. It does not matter what date I select, it keeps saving a day less than the day I selected.
The date it's saving is in UTC, which is the timezone you ought to be using on your server(s) and database(s) - that's a good thing as it removes timezone related info and allows dates to be localized to any timezone.
When you transmit date values over the wire between the server and the browser, make sure you're using RFC-8701 formatted strings (what you get when you call new Date().toJSON() in JavaScript). Then you won't have to worry about timezone issues, as RFC-8701 dates are always in UTC. The browser will take care of transforming dates to local time - just call new Date(myRfcDateString).
More info: Storing date/times as UTC in database
Use convert method of store to process data for date column before storing it in store data. Then the store data will be submitted to server in proper format.
There was similar question asked, links below -
Question - Datefield in grid editor
Fiddle - https://fiddle.sencha.com/#view/editor&fiddle/2e0a
In the datawarehouse we need to capture date and time value with timezone as received from source application DB. But Postgresql is converting those values into native timezone every time. Is there a way to maintain source provided timestamp with timezone value in Postgresql database as is?
E.g. from source DB if we get the timezone value as "01/20/2010 11:15:33.000000 -06:00" , want to store this value as it is in warehouse which is at different timezone. Is there any way to do that in Postgresql?
There is no native way to store the source time zone, all timestamps with time zone are stored as UTC. You can extract the time zone and store it in a separate column, and then use a view to provide the data at the time zone you want.
Let's say that I need to create 'chat-like' system. Of course I need to deal with dates somehow.
I read about it a lot and I have some knowledge but I really don't know how to use it.
I would like to store message date in UTC (postgres 12)
Each user should be able to select his time zone and this time zone should be saved into database (standard approach)
When message is retrieved from database I need to convert message date into valid local date based on user selected timezone.
This is really all I need to do and here problem starts:
In postgres date is stored with offset f.e 2020-05-01 00:00:00+02, but I want to store timezone in another table, not here
How can I store user timezone? I should use names like "EST5EDT" or use time offsets as integer?
Where can I find list of all timezones to present user? (Each global website f.e. facebook has list of timezones with offsets, where can I find list of all valid timezones?)
How can I select date with user appropriate timezone? f.e.
SELECT convert_to_user_date("Date", "timezonename??")
FROM "Messages"
Is this correct way to achieve my goal?
These days you don't have to resort to UTC. You can store full timestamps with time zone. This way e.g. you won't lose DST status at the moment the timestamp was recorded in the database.
https://www.postgresql.org/docs/current/datatype-datetime.html
You can easily select the timestamp stored with any time zone shifted to target user's time zone (assuming it's stored somewhere in user preferences). The syntax is SELECT ... AT TIME ZONE
https://www.postgresql.org/docs/current/functions-datetime.html#FUNCTIONS-DATETIME-ZONECONVERT
You are very close to a workable setup.
First, use timestamp or timestamp without timezone column data type to store those UTC date/time stamps.
Second, store your users' preferred time zones in varchar(63) columns in the form Asia/Kolkata or America/Halifax.
Third, use postgresql's built in view pg_timezone_names to get a list of valid time zones. You can use it to populate a pulldown list of choices in your user-settings screen.
If you have time for some real excellence in your user-settings screen, you can suggest time zone settings you guess from the users' ip adresses and allow them to change them if your guess was wrong. Read this. How to get Time Zone through IP Address in PHP
Then, when your application starts using postgresql on behalf of any user, look up that user's chosen time zone in your users table, and use it in this SQL command. SET TIME ZONE 'America/Halifax'; (whatever the user's choice is).
Then when you retrieve your time stamps, they will be rendered in the user's local time, and when you store the they'll be in UTC.
The 'toobz are full of advice about this. Here's something that might be useful. How to get Time Zone through IP Address in PHP
Use the data type timestamp with time zone. Don't be worried by the name — that data type really represents an absolute point of time and does not store time zone information.
The only thing you have to do is to set the timezone parameter correctly for the time zone of the client connection, then the value will be represented correctly in that time zone. PostgreSQL does all the work for you.
If you don't like the string representation (e.g., you are disturbed by the time zone offset displayed), use to_char to format the output the way you like:
CREATE TABLE dates (x timestamp with time zone NOT NULL);
SET timezone = 'Europe/Vienna';
INSERT INTO dates VALUES ('2020-06-01 03:00:00');
SET timezone = 'Asia/Kolkata';
SELECT to_char(x, 'YYYY-MM-DD HH24:MI:SS') FROM dates;
to_char
---------------------
2020-06-01 06:30:00
(1 row)
I save my date as a local date, but when I read it back, it treats it as if it was a UTC date so it slips by several hours.
The dates are passed in as strings in the form '2020-03-05 09:05:23' as query parameters but when they are retrieved they might look like '2020-03-04 10:05:23' because I am 13 hours ahead of Greenwich.
For MariaDB (or MySQL):
Use DATETIME as a picture of the clock on the wall.
Use TIMESTAMP to adjust to the system's timezone.
Set the system's timezone according to where it lives in the world.
I have column 'event_date_time' in my 'events' table with type 'timestamp with timezone'. My python flask application is saving date like '2014-08-30 02:17:02+00:00' but postgres automatically converts it to '2014-08-30 07:17:02+05'. It converts the timestamp to my local timezone i-e Pakistan. I want to save it without converting.
I have tried
set timezone='UTC'
and it does change timezone to 'UTC' but pgadmin3 is still saving the converted time.
I am using MAC OS and Postgresql 9.3.
The reason pgadmin is displaying hours +5 is because your system timezone is set to this.
When you save a "timestamp with time zone" value at GMT + or - any value, the system offsets whatever timezone your input was to GMT (or UTC), so that when you go to retrieve it, you can specify the timezone you want it displayed in.
For example let's establish a current time for say... New York.
select now()::timestamp with time zone at time zone 'America/New_York';
At the time of asking it returned '2014-08-23 08:50:57.136817'. 8:50 Saturday morning, or 8:51 if you're being pedantic.
Now if we take that same time and display it in GMT we will see a different result:
select '2014-08-23 08:50:57.136817 America/New_York'::timestamp with time zone at time zone 'GMT';
Now have a new time of '2014-08-23 12:50:57.136817'... 5 hours into the "future"!
Finally let's get the original timestamp and display it in what I believe is the Pakistan time zone (PKT) and see what it shows
select '2014-08-23 08:50:57.136817 America/New_York'::timestamp with time zone at time zone 'PKT';
The result? '2014-08-23 17:50:57.136817' further into the future still!
Again I must stress the reason it can do this is because it is always converting the input time offset to UTC or GMT. Postgres processes all of its "timestamp with time zone" data types in this way. It is designed to avoid time zone problems such as daylight savings and so on.
Your issue appears to be that python is inserting the time at an offset of +00, and if this was supposed to be a local time then you will be 5 hours off as far as postgres is concerned. Without knowing exactly what queries python is making, I would assume you may want to look at that to make sure it is giving you the correct time, presumably set timezone='PKT' should be a fix. Either way, when you are viewing timestamp with time zone using a browser such as pgadmin, the timestamp is being converted to your local timezone and this is why you see +5.
Alternatively if you do wish to see those times at +00 then you must specify that you want this in your SELECT queries.