I am currently building an out of office workflow in Microsoft powerautomate for Teams. When a request for 8/19/20 gets submitted it gets changed to 8/20/20 and same thing with the end date. Is there a way to set a it so it shows the actual dates selected?
So i think this is happening due to Default UTC time zone is used by Power Automate. Here is a flow that uses the Convert time zone action with a base time of utcNow(). Convert the time to needed timezone and then used an Update item action to update a date field with that converted time value. The correct time shows up in my SharePoint list
Hope this may help you.
Related
I am using Microsoft Dynamics 365 Web API approach to interacting with CRM data.
Here I want to update the field with type: DATE and TIME.
Date value I am passing in the request body is as below:
"packfirstday":"1-15-2018"
Except for above, I have also tried with DateTime and with different date formats.
e.g.
mm-dd-yyyy
m-dd-yyyy
mm/dd/yyyy
yyyy/mm/dd
yyyy-mm-dd
PS: I try to post without date field it is saving details successfully.
The problem is not with the code, the simple misunderstanding.
There are 2 components namely Behavior & Format. You have Format set as 'Date only' not the Behavior. Behavior decides the Database terms whereas Format is used for displaying datepicker controls in Form.
So when you set the field in web api with only date part - the CRM database expects time part also.
Either set behavior also as date only, so this will work:
"packfirstday":"2018-01-15" //YYYY-mm-dd format
Or change your code to pass time part also:
"packfirstday":"2018-01-15T11:10:00.000Z" //UTC offset
Since user local behavior still expects the time part.
I am working on my first application for mac which uses Core Data. Since I don't have much software development experience I would like to ask the more experienced developers the following question:
When entering data in some of the forms, user will have to enter a date in couple of the forms. Since app will be on app store and people from different continents will download it (I hope so) I am thinking of allowing the user to select his preferred date format from the preferences panel that I have in my app.
But I am wondering what will happen if after entering 500 or more records, he decide to change the date format again? Will that cause a mess in core data eventually?
Is this good idea or I should keep things simple and just get the system date (user computer date format) and use that date format? What would you do? Any advice will be deeply appreciated.
My advice is to keep date as timeinterval. You can see such method for NSDate.
The interval between the date object and 00:00:00 UTC on 1 January 1970.
So if you get NSDate object from NSDatFormatter object you will be able to obtain time in seconds since 1970. You could store this value in Core Data and use it later for creating NSDate objects. You will be able to use it for different locales and time zones as well as use the correct format.
'Dates' is complex topic and I suggest you to read guides about dates and date formatters.
First is to decide how you should store the date. The answer here is as an NSDate. The NSDate is a single unique precise point in time, thus it in a sense stores both date and time.
This means that for example 1 PM in Berlin and 8 pm in Kuala Lumpur will be the exact same NSDate value (during winter months) but 2 pm in London and 2 pm in Paris the same calendar date will not be the same NSDate value. This is a quite complex topic, read the date and time programming topics documentation from Apple.
Then as you say you need to allow you user to input the date. The way to do that is to use a NSDateFormatter tied to your input control. The formatter can be defined to be as per system settings, which means you will get the localisation you are seeking for free, so that is in fact easy.
The tricky thing you are really facing is to determine what you are really looking to store if it is only the calendar date without an associated time you want to store. For example you decide store the date combined with 12.00 noon in the local timezone. Then if the user shifts to another timezone more than 12 hours away the date may be displayed as the previous date or the next. The safest bet is to store the date combined with 12:00 noon GMT as this is in the middle of the time zone range. There are a few locations 13 and 14 hours off that could exhibit the mentioned problem anyway, but these are small atolls in the pacific and could possibly be safely ignored.
However the the best thing is if you can in fact determine that what you are looking to store is really a precise point in time rather than a date (which is a 24 hour fuzzy definition). For example in a calendar app an event usually takes place at a specific time on a specific date, then store that time and date.
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.
I have a custom object with Start and End date fields, and also a Status field.
When a new record is created, if the Start date specified is in the future, I would like to be able to have a Workflow update the Status field to 'Active' when the Start date is today. However, I only appear to be able to select a fixed number of days after which my Field Update task can be triggered. What I want is to set that number of days equal to Start date - Today's date.
Can this be done?
OK, I realised I can set the time delay to zero days after the Start date. Not intuitive (For me), but it makes sense.
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.