Date & Time UTC Conversion deactivation option

[JohnnyPrescott]

Hi,

I am wondering why after so long why is BluePrism doing the auto conversion of Date & Datetime to UTC. It is definitly the most annoying thing in BluePrism. It is literally frustrating to work with anything Date related in the software.

Why not give the ability to deactivate this conversion that it always does? Even when your datetime is already in UTC time, it will convert it anyway, making your date so out of whack that it doesn't make sense anymore... and don't get me started on collection with date where you need to loop in the collection. You can get them converted a lot and making your process a lot harder to develop because you need to account for those instead of just doing that yourself if you need to.

BluePrism should never touch any variable automatically without the dev actually doing something.

using  DateTimeKind works for the first time when you output but BluePrism clears that after that point so it doesn't really matter what kind it is.

Please let user do their things. I know I am not the only one having trouble with that. I saw in another company devs that were using SQL query to get the "Now()" date instead of Blueprism cause it was more reliable. That's not normal to have to do workaround like that for anything.

I've been working with BluePrism since version 4 and this is by far the worse thing that has been following us since then.

regards,

[diane.sanzone]

I agree that the date time auto-conversion to UTC is quite frustrating.  I would add this is especially difficult when dealing with queue items.  If you view the queue from control room, you see things in local time, but then if you try to add something to queue, filter the queue based on date, or even defer something, Blue Prism uses whatever you send in as UTC.  I'm in the US so this even alters the time by an hour depending on the time of year.  Please have consistency throughout the application. Either everything is in UTC and we have to convert to output local, or everything is local and we have to convert to use UTC. The mix is frustrating, confusing, and causes errors. I've had three development efforts in the last week identify issues with these automatic conversions. It has cost my team at least 4 dev hours and 15 lost testing hours as a result. There is a cost here, beyond frustration.