Control UTC time in server side Dynamicscrm - dynamics-crm

I saved a record in 17:16:15, I run a job which gets the ModifiedOn field of my record and I got- 15:16:15, my GMT is +2, I want to know how to fix that gap that my result will turn out like it should be - 17:16:15. I can't select it from DB I need a solution in server side (c# I mean) what can U do in that case?

DateTimes are always saved in UTC in the database. *
You need to dynamically convert from UTC into your local time zone. In C#, you can do this with the .ToLocalTime() method as long as your code is running in the correct time zone. You can also find your local time in the FormattedValues collection of the response, which uses your Dynamics timezone user settings . But the raw datetime value in the database will always be in UTC.
* The only exception to this is if the DateTime field is set to “TimeZone Independent” in the attribute type settings. But be careful: once you set this option you can’t change it for that field again.

Related

Why selecting a date\time range into Kibana the query is performed with wrong dates? URL parameters are wrong

I am working on a project involving ElasticSearch and visualizing data on Kibana and I am finding the following problem with date range selection.
As you can see in the following picture I selected I time range that starts from April 8 2021 at 00:00:00.000 and end at April 10 2021 00:00:00.000 . Then I clicked the Refresh button in order to perform the query.
The problem is that, as you can see in the highligher URL section the passed date range into the query is wrong !!! Infact this is the timerange section of my query into my URL parameters:
time:(from:'2021-04-07T22:00:00.000Z',to:'2021-04-10T10:00:00.000Z')
As you can see it is pretty differnt from what I selected into the start and end date form fields.
Changing the values into the start and end date form fields automatically changes also the values into the URL parameters but they still wrong.
What could be the problem? Why selecting dates and time into these form fields the parameters value are wrong? What could be the cause of this issue? How can I try to fix it?
I suspect something related to the server timezone (the server where Elastic\Kibana) are installed or something related to some Kibana configuration but I really have no idea
The kibana docs specify:
The timezone that Kibana uses. The default value of Browser uses the timezone detected by the browser.
So (I'm assuming) your browser default timezone is UTC + 2, meaning when you select 00:00 it's converted to 22:00 UTC timezone, The Z in 2021-04-07T22:00:00.000Z is in indicator here.

Should I store the local time for events instead of UTC?

I am currently storing events of some entities in UTC time but I am not sure if I should do that in this case. Imagine there's an event at 10pm local time (-4h UTC) and a mobile App fetches "todays events". This could e.g. look like this:
App sends request to fetch all clubs in the near location
After receiving all clubs it sends a request to get all events for today. It therefore sends the local time Sun. 10pm to the server.
The server would convert the local time of the mobile device to UTC Mon. 1am and fetch all events from Monday. But of course that was not what I wanted.
Fetching all events from the clubs and convert them to their local time using their local time offset information is not really a great solution.
So wouldn't it be better to just store all events in local time? In that case the mobile App would send its local time to the server which would be able to query all events from the clubs in local time as well.
This sounds much simpler to me but I am not sure if I overlook something.
So what would I do in this case?
Yes, storing everything in UTC is probably the best solution.
You don't say how you are "storing" the dates/times, but if you are using Dates or Joda equivalents, then you should know that their underlying representation is effectively in UTC (they represent a moment in time as an offset in milliseconds since the "Epoch", which is Midnight, Jan 1, 1970 UTC). These dates only have a timezone when you format them as Strings.
Most databases do something similar (store the date in a common timezone, usually UTC). The major exception that I've found is the generally available date-time related column types in MS SqlServer which by default store everything in the local timezone of the server.
Also be aware that if you use SQLite, and you store a date/time by passing a String in SQL that contains a timezone, SQLite will store it without warning, but will ignore the timezone and assume that the timezone is UTC, giving you a result other than what you might expect.
For more on this, see my (old) blog post at http://greybeardedgeek.net/2012/11/24/java-dates/
The other answer is correct. Some more thoughts here.
A time zone is more than the offset from UTC mentioned in the Question. A time zone is also the set of past, present, and future rules for anomalies such as Daylight Saving Time. You should refer to a time zone by its proper name, continent plus Slash plus city or region. Never use the 3-4 letter codes such as EST or IST.
To search for events in the user's "today", you must know the user’s time zone. For example, a new day dawns earlier in Paris than in Montréal. After the stroke of midnight in Paris we still have a few hours of “yesterday” left to go in Montréal.
While you can make a guess as to the user’s time zone, the most reliable way is to ask the user.
DateTimeZone zone = DateTimeZone.forID( "America/Montreal" );
DateTimeZone now = DateTimeZone.now( zone );
DateTime today = now.withTimeAtStartOfDay();
DateTime tomorrow = today.plusDays( 1 );
// Search for events that start >= today AND that start < tomorrow.
To search Joda-Time objects, use the Comparator built into DateTime. That comparator works across objects of various time zones.
To query a database, convert that pair of DateTime objects into java.sql.Timestamp objects. You do that by extracting and passing the count of milliseconds since the epoch of 1970 in UTC.
long m = today.getMillis();
java.sql.Timestamp tsToday = new java.sql.Timestamp( m );

Parse.com - Who sets updatedAt and createdAt properties?

Title is pretty much the question, when PFObject is created what values are stored in updatedAt and createdAt properties? Are those values from local device time or they are world time and 100% correct.
I need somehow to store a current world date, without letting user to trick my app by switching the date in setting.
Parse.com set it for you in order to let you keep track of the created date and updated date. Time zone is PST so that when you should set PST as your time zone from your time handler object and it will offset it for you automatically.
EDIT: I have this experience before when I was working with my Indian coworkers. The default time zone GMT and it will not work unless Parse.com returns GMT time zone. So, we have to set PST as time zone in our time handler object and it will offset properly.
You should consider those values are set / updated by parse when data hits the server and treat them as almost private as you don't have direct control. If you need to protect some information then you should use cloud code to update it and set appropriate ACLs to prevent access to it from other routes.

UTC DateTime problems

I currently store all dateTimes in the DB as UTC dates. Each users time zone offset is also stored in the DB. When I retrieve a Date it is converted back to their local date using this offset.
The problem occurs when I retrieve a date using an ajax call. The date (which is already converted using the offset) is, I think, returned as a Java Date object. The browser then decides to mess with my Date adding the clients computers time zone offset to the Date object. This is causing dates to be a day ahead of what they should be if the time component is more than 11.59am.
The only solution I can come up with is to pass them as strings in which case this of course wouldn't happen. This is a laaaast resort for me though and I would love to find a better solution or workaround for this problem.
Your browser is not messing with the dates given that browsers don't have a native date transfer variable. You have something else that is doing that. How are you sending your dates in ajax? Json? Json will only send numbers or strings. XML will only send strings.
Something is converting your sent date into a javascript date object, find out what it is.

Display DateTime data in users TimeZone in DataTable

We have a reporting application where all DateTimes are stored in UTC in the database (SQL server 2005)
The reporting application works simply be retrieving a DataTable and binding to a DataGrid displaying the information.
If we know the logged in users time zone (e.g. +3 GMT), is there any way to update the DataTables dates which are in UTC to now display in the users time zone?
We know we can spool thorugh each column/row in the DataTable and do a conversion but is there a better more efficient way?
I would modify the time as it is displayed to the user. Keep how it is stored consistent, but also store what their timezone is, and then modify the UI to show the correct local time. For example, if their time zone is Central Standard Time, then you could use something similar to the following code:
SomeDataObject someDataObject = new SomeDataObject();
someDataObject.TimeZone = -5; //UTC Timezone for Central Standard Time
someDataObject.Time = DateTime.Now;
DateTime someTime = someDataObject.Time;
someTime.Add(someDataObject.TimeZone); // Display this back to the user
If using .NET, there's a built in class that was made precisely for this purpose. TimeZoneInfo (http://msdn.microsoft.com/en-us/library/system.timezoneinfo.aspx) as taken from the article:
A TimeZoneInfo object can represent any time zone, and methods of the TimeZoneInfo class can be used to convert the time in one time zone to the corresponding time in any other time zone. The members of the TimeZoneInfo class support the following operations:
Retrieving a time zone that is already defined by the operating system.
Enumerating the time zones that are available on a system.
Converting times between different time zones.
Creating a new time zone that is not already defined by the operating system.
Serializing a time zone for later retrieval.
Hope this helps.

Resources