Time Zone- being able to update it on hosted RE

I discovered yesterday that when I use the time stamp (F5) in my action notes that it is using EST, I am in CST. After a chat with a wonderful BB rep, we found out that it is not an option, and that the hosted folks are defaulted to the time zone where their server is. 

It would be great to be able to change to the time zone where we actually are for accuracy.

  • Sharon Sandberg
  • Mar 16 2018
  • Attach files
  • Curtis Cecil commented
    30 May 14:32

    This would be great for the JustGiving integration into RE/NXT as well. We saw gifts come in yesterday evening that were showing today's date when we went to batch to process them.

  • Guest commented
    January 04, 2022 13:58

    Our datacenter must be two hours off from our time zone as web transactions that come in from 10 pm to 12 midnight are added to RE the following day. This causes problems and extra work to balance the days transactions when they process in BBMS one day, but are not added to the database until the next day. It even splits web view batches into two different days. It would be very helpful if we had control over the time zone used as we do in Database View.

  • Megan Girvalo commented
    November 05, 2020 21:34

    Our organization has found this problematic when working with Workflow. We are trying to send automated emails to arrive first thing in the morning on specific days but due to the location of our data centre, emails actually get late in the day at 11PM. Would be great to have some flexibility with this or to designate the exact time a workflow email would be sent each day.

  • Heather MacKenzie commented
    May 25, 2018 19:15

    What?!?  I am just discovering this now when we've been on NXT for a year already?  Why isn't this part of the information given out right at the beginning.  Sounds perhaps VERY important to know to me.

  • Steven Cinquegrana commented
    April 25, 2018 02:35

    It certainly makes sense to allow for an organization-centric time-zone or offset. That would still work for, say, a mobile user traversing the globe as well. It seems very rigid to insist on the server's time-zone. And what if the organization's server was moved to a different time-zone at some point?