I am currently querying a custom endpoint I have created where using a $filter parameter with for example LastModified gt DateTimeOffset'2022-12-12T01%3A33%3A29.583%2B00%3A00' (LastModified gt DateTimeOffset'2022-12-12T01:33:29.583+00:00')
The lastmodified date that value is always in UTC time?
Just want to check so I can convert my local Now date to UTC before hand so the result of the query is correct. I am just a bit confused by this as on my local instance hosted on my own machine the lastmodified date is saved in local time.
Thanks
Acumatica does store datetime in UTC format but review the tips and tricks in the link below to display time in the user's time zone:
https://asiablog.acumatica.com/2019/02/generic-inquiry-tips-tricks.html
Related
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.
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.
There are two clients with same window application. One is in India and other one is in Belgium. Sql server and web service application is hosted at Belgium. In sql I am storing UTC date time.
Now issue is a time difference for this two clients. I want to show UTC time in history form that mean what is stored in Database I have to bind that data to gird. No any extra code because I suppose to bind UTC date-time. Event then I get time difference for this two client.
Blue header screen is of a Indian client and other one is of a Belgium client. In Belgium time is showing exactly as in Database but difference is for India. Am I missing anything in configuration or what?
You have to convert both time zone in standard UTC and save it. Used dateadd() function to manipulate datetime. such as
declare #IST_date datetime
declare #BE_date datetime
declare #UTC_date datetime
--Indian standard time is (GMT + 5:30 hrs)
-- Belgium standard time is ( GMT + 1 hour)
select #UTC_date = DATEADD(hh,5.30, #IST_date)
select #UTC_date = DATEADD(hh,1, #BE_date)
why not simply convert the value at display ?
DateTime MyDate = Data["ChangedDate"];
DateTime MyDateUTC = MyDate.ToUniversalTime();
tadaaaaa
Ditch System.DateTime and use Noda Time!
Getting Started with Noda Time
System.DateTime uses the system culture and time zone at unpredictable moments, where Noda Time works without any defaults. Takes a bit of work to understand, but you'll never look back.
Use Noda time on the client, and store all the values in UTC in the database. You may also wish to store the original time zone that the date time was entered in.
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.
I am developing report using SQL Report Builder 2.0, In this I am passing the timezone offset value as a parameter (-04:00). Using "TimeZoneInfo" I am getting all the timezones available from the system. But I am checking the timezone with the offset value, so from the list available I can only get the first timezone object.
Is there any other ways to get a specific TimezoneInfo from the system.
Thanks,
Veera
This will return the Timezone offset.
System.TimeZone.CurrentTimeZone.GetUtcOffset(now())
This will return the Local time.
System.TimeZone.CurrentTimeZone.ToLocalTime(now())
This will display the time zone name
System.TimeZone.CurrentTimeZone.StandardName
When running the report on the server, it will show the Server's timezone. One quick way to deal with that is to just show the time & the timezone name.
If you really must show each user their local time, you should probably store the UTC offset against one of the geography tables in your database i.e. office or location. You could also store it against user names (User ID is a global variable available in SSRS) but that would be more maintenance.