When we are talking about Localize yes/no we are really talking using the UTC timezone (Localize No) or the Session timezone [* 1] (Localize Yes)
It is important to always use the correct date operation otherwise you will see discrepancies in the result of the operation. Even the addDays operation could give unexpected results if you execute it on the wrong attribute type. I have never done research on why this happens but I have seen that addMonths on a datetime attribute, with Localize No, can be several days! off what I expect.
It does not matter if this action is executed in a scheduled event, or after clicking a microflow button. You should always use the correct date operation to avoid unpredictable differences.
Comparing two dates is always challenging, you have to be aware that the dates are only equal if they are equal up till the millisecond. Even if you have two birthdays on the same date, if one birthday has .0001 millisecond and the other is set to .0 millisecond the dates will not be equal.
Therefore you should perform the validation and think about what to do with the timeunits smaller than what you care about.
If you care about the year-month-day you need to write the proper expression to ignore the hours, minutes, seconds.
In other words, the expression
$dateVariable = $AnotherDateVariable is not recommended. This is likely to cause you problems.
So how should you compare dates?
As you mentioned in your question the platform stores the dates for Feb 10 (10-Feb-2015, stored as 9-2-2015 23:00:00 and 10-2-2015 00:00:00). A the localized date will grab the value from your database and translate it to your timezone.
In this example the first date 9-Feb 23pm, in timezone GMT+1 this is 10-Feb 0am. (localized yes)
The second date 10-Feb 0am, will be pulled from the database without changes. (localized no)
If you compare these dates with the equal expression in a microflow the runtime will always translates the dates to the same timezone before comparing them. Even if the users sees the exact same values, if you check $date1 = $date2, the platform will evaluate this as: (15/2/9 23:00 UTC = 15/2/10 00:00 UTC) therefore the expression will return false.
I think the platform should be able to support you better in this, but this is what it is.
The safest way of doing this, and eliminating all variations would be the expression below:
parseDateTimeUTC( formatDateTime($MyObject/TheLocalizedDate, 'MM/dd/yyyyHHmmss.S') ,'MM/dd/yyyyHHmmss.S') > $MyObject/TheNotLocalizedDate
Or just compare the string values if you want the days to be equal.
formatDateTime($MyObject/TheLocalizedDate, 'MM/dd/yyyy') = formatDateTime($MyObject/TheNotLocalizedDate, 'MM/dd/yyyy')
[* 1] A Session timezone is the timezone using which data is being retrieved or a microflow is being executed.
Every action (microflow and client) has a session. The session of an action triggered by the user will be in the timezone known by the browser. A user can overrule the microflow timezone by selecting a timezone in the user_timezone relationship. (I would recommend to make sure the relationship is always empty)
The timezone from scheduled events is configured in the project settings.
Never compare stored values of localized and non-localized dates. This can lead to mentioned problems If you want to compare values, first convert them by using an expression as mentioned above in Jaspers answer
As I understand it, localize only determines how a date is displayed in the browser. If this is the case, then localize would not have an effect in a microflow, as microflows run on the server.
P.S. relevant info from the doucmentation:
Localize (only attributes of type 'Date and time') This property indicates whether the date and time should be localized. By default localization is enabled. If you are not interested in the time component of a date (e.g. a birthday), you should set this property to 'No'. Otherwise, the date can change because of time zone differences: a date and time early in the morning on April 2nd in Europe will be on April 1st in the U.S.A. In technical terms, this property indicates whether the client assumes that the date and time are in a local time zone (Yes) or in UTC (No). In the former case, the date is first converted to UTC before being sent to the server and converted from UTC before being displayed.