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.
Related
I'm struggling to deal with time zone and daylight saving when querying SAP HANA. The datetime stamp is in the form of NVARCHAR, eg 20210304132500 YYYYMMDDHHMISS in UTC, which means local time is 14:25:00(GMT +01:00) but my query returns 13:25:00 (UTC). How do I edit my results to match local time? Sample query below if that helps.
SELECT DATE_TIME,LOCATION,PART_NUMB
FROM "PUBLIC"."internal.sap.datamodel::ACTIVITY"
WHERE SUBSTRING(DATE_TIME,9,2) IN ('08','11')`
The desired result is local date_time in any format.
HANA comes with timezone conversion functions (UTCTOLOCAL) that can perform the necessary calculations.
These functions require that the data/time input is in either SQL date/time format or that it can be converted to that. They also require that the timezone data has been set up and maintained in the HANA DB. This is the actual information about which timezone has which offsets and daylight saving begin and end times.
For your example, it may make sense to expose the DATE_TIME as a type converted field DATE_TIME_UTC that is already in sql-date time:
to_seconddate (DATE_TIME, 'YYYYMMDDHHMISS') as DATE_TIME_UTC
With this conversion done, you can convert the timezone like this:
UTCTOLOCAL (DATE_TIME_UTC, 'Berlin', 'platform') as LOCAL_DATE_TIME
Note, that the target time zone name may be something like "GMT+1" but this is really just a name and not a calculation instruction. If "GMT+1" is not found in the list of timezone conversions, HANA won't just add an hour - it won't perform the calculation.
With this data type and timezone conversion done, you could have a WHERE clause like this:
WHERE
HOUR(LOCAL_DATE_TIME) IN (8, 11)
This order of transformations (data type -> time zone -> hour component) is of course rather expensive. It may be worthwhile to check whether the resulting query performance is satisfactory on realistic data volume.
Also important to note is that time zone conversion only works on complete date-time information, not just the time. That is to say, if the date is unknown, it cannot be determined which offset rule between two time zone applies. So, simply separating the hours and date components won't help in this case.
Finally, I've written quite a bit about handling date, time, and time zones in HANA, you may want to have a look at that:
The time is now, isn’t it?
Trouble with time?
You got the time?
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.
can I adjust time settings in the application so that correct times (in terms of my TZ) are saved? Or do I have to adjust the server time?
Time zones are handled in Moqui in a standard way. The point in time in Timestamp objects has no time zone (milliseconds since epoch) so the time zone only comes into play when converting it to another form, such as parsing a String from user or other input or printing a String... or in some cases saving to and loading from a database.
Some databases use a no timezone internal representation, for others ALL Timestamp, Date, Time objects are saved and loaded using the database time zone. The database time zone is set using the entity-facade.#database-time-zone attribute in the Moqui Conf XML file, or if not set defaults to the server's time zone (ie Java's default time zone).
I'm working on a project where I have to gather data from GPS devices located in different countries (timezones + daylight savings) and display those data to different users also from different countries. I'm thinking about saving the date in UTC format (that is what I receive from the GPS device) but then again I belive I'll have trouble converting that date to the user's local date (I have to display historical data also so I'll have to account for daylight savings for the given date). Maybe the datetimeoffset datatype would be more appropriate but how would I go about converting the received UTC date to the datetimeoffset datatype? What would you suggest? Thanks!
As you don't have to store any time zone along with the datetime, you can store them as UTC. That has the advantage of being linear, and easy to document. You don't have to bother with gaps and overlaps at the daylight savings time switches.
Convert the date to the local time zone when you display it to the user. It doesn't make sense to convert it to a local time zone until you know which user will be viewing the data.
I usually have an "interceptor" that right before reading/writing from/to the database does DateTime conversion (from UTC to local time, and from local time to UTC), so I can use DateTime.Now (derivations and comparisions) throughout the system without worrying about time zones.
Regarding serialization and moving data between computers, there is no need to bother, as the datetime is always UTC.
Should I continue storing my dates (SQL 2008 - datetime) in UTC format or should I instead store it using DateTimeOffset (SQL 2008 - datetimeoffset)?
UTC Dates in the database (datetime type) have been working and known for so long, why change it? What are the advantages?
I have already looked into articles like this one, but I'm not 100% convinced though. Any thoughts?
There is one huge difference, where you cannot use UTC alone.
If you have a scenario like this
One server and several clients (all geographically in different timezones)
Clients create some data with datetime information
Clients store it all on central server
Then:
datetimeoffset stores Local time of the client and ALSO offset to the UTC time
all clients know UTC time of all data and also a local time in the place where the information originated
But:
UTC datetime stores just UTC datetime, so you do not have information about local time in the client location where data originated
Other clients do not know the local time of the place, where datetime information came from
Other clients can only calculate their local time from the database (using UTC time) not the local time of the client, where the data originated
Simple example is flight ticket reservation system ... Flight ticket should contain 2 times:
- "take off" time (in timezone of "From" city)
- "landing" time (in timezone of "Destination" city)
You are absolutely correct to use UTC for all historical times (i.e. recording events happened). It is always possible to go from UTC to local time but not always the other way about.
When to use local time? Answer this question:
If the government suddenly decide to change daylight savings, would you like this
data to change with it?
Only store local time if the answer is "yes". Obviously that will only be for future dates, and usually only for dates that affect people in some way.
Why store a time zone/offset?
Firstly, if you want to record what the offset was for the user who carried out the action, you would probably be best just doing that, i.e. at login record the location and timezone for that user.
Secondly if you want to convert for display, you need to have a table of all local time offset transitions for that timezone, simply knowing the current offset is not enough, because if you are showing a date/time from six months ago the offset will be different.
A DATETIMEOFFSET gives you the ability to store local time and UTC time in one field.
This allows for very simple and efficient reporting in local or UTC time without the need to process the data for display in any way.
These are the two most common requirements - local time for local reports and UTC time for group reports.
The local time is stored in the DATETIME portion of the DATETIMEOFFSET and the OFFSET from UTC is stored in the OFFSET portion, thus conversion is simple and, since it requires no knowledge of the timezone the data came from, can all be done at database level.
If you don't require times down to milliseconds, e.g. just to minutes or seconds, you can use DATETIMEOFFSET(0). The DATETIMEOFFSET field will then only require 8 bytes of storage - the same as a DATETIME.
Using a DATETIMEOFFSET rather than a UTC DATETIME therefore gives more flexibility, efficiency and simplicity for reporting.