Background context
It has been reported that the date on the journal entry created when contact marketing consent changes has a date an hour in the past. It's likely this is because a Utc date is being use exclusively, rather than considering the local timezone (or the customer's timezone, which is probably more appropriate)
Specification
Recreate the issue by altering the marketing consent of a contact via the API
A brief look at the code suggests the problem is going to be in Reapit.Packages.Journalisation.JournalEntryBuild.BuildSharedNoficiation/BuildNotification which appears to be using DateTime.UtcNow exclusively.
Come up with an appropriate means of considering the customer's timezone when building the notification to ensure that the created date of the journal entry is correct for the database timezone
Background context It has been reported that the date on the journal entry created when contact marketing consent changes has a date an hour in the past. It's likely this is because a Utc date is being use exclusively, rather than considering the local timezone (or the customer's timezone, which is probably more appropriate)
Specification
Reapit.Packages.Journalisation.JournalEntryBuild.BuildSharedNoficiation/BuildNotification
which appears to be usingDateTime.UtcNow
exclusively.