Developer forum

Forum » Ecommerce - Standard features » Timezone considerations

Timezone considerations

E-mail notifications
Scott Forsyth Dynamicweb Employee
Scott Forsyth
Reply
Posted on 13/08/2021 22:42:07

Hello,

We ran into an issue about a year ago that we worked around, but I'm reporting this now so that we can get a permenant fix. It will likely impact some other users too.

What I've found is that, if the web server and database server have different timezones, some issues can occur in the platform. There is one issue that I'm aware of which is if you import a customer, the StartDate (Options -> Publication period), and the database server is ahead of the web server's timezone, then it will create the record with a date in the future. For example, if we have webserver = EST and database server = UTC, at this time of year, it means that a new user won't be active until 4 hours after they are created.

We ran into this when moving our sites/servers to Azure (Azure VM + Azure Database). Azure Databases don't support changing the timezone, so they are set on UTC and we can't change that. However, we set our web servers to EST which is convident because of the time in the scheduled tasks in the backend, and order dates and times in the frontend are in our timezone.

After we discovered this issue, we were forced to set our web servers to UTC to work around this. It would be nice to be able to switch our web servers back to our local timezone. We're getting issues that come up with the inflexibility of this.

I reported one known situation above, but I recommend reviewing all date fields in the platform to confirm that it's always using a consistent time (UTC) rather than local time. 

Thanks!

Scott

 


Replies

 
Morten Bengtson Dynamicweb Employee
Morten Bengtson
Posted on 27/08/2021 09:16:19
Reply

Hi Scott,

We have had some discussions about these issues on the development team - and we agree that this is something we need to look into.

There are two separate issues:

1) Mixed use of SQL (database server) and .NET (web server) datetime.
You mention that you have already reported one issue related to users. Do you have a bug number or case number on that?
We will review other uses of sql datetime functions and make changes where it is needed.

2) Persisting datetime as local time vs UTC
It would be much better to use UTC, but it requires some fundamental (breaking) changes. That doesn't mean that we won't make the change at some point, but it's  just not at the top of our list right now.

Thanks for the feedback. We really appreciate it.
/Morten

 
Scott Forsyth Dynamicweb Employee
Scott Forsyth
Posted on 31/08/2021 02:17:42
Reply

Hi Morten,

Great, thanks for considering this. 

I didn't report this yet. I just meant that in the post above, I provided details for the one known situation. That's with using a data integration job to create a new user. The following should be steps to reproduce it (I didn't specifically test it recently but I hope that I'm sending you down a good path):

  1. Set the timezone of the sql server to something like UTC
  2. Set the timezone of the web server to something else, for example EST. It would be easier to see the issue if the web server is some timezones earlier than UTC.
  3. Create a simple import using something like Excel for a new user
  4. Create a data integration job that imports and creates that user
  5. Run the import
  6. The user's start time should be for some hours in the future and it won't be able to be used yet, until that time has passed

Regarding your #2 point, for things like the scheduled tasks in the backend, doesn't that already show in the local web server's timezone? If so, that's all that we need (it already works). So, you can store everything in the database consistently in UTC, but the existing places in the platform that display in the web server's timezone, just leave those as they are. I realize that it's not consistent and logs will tend to be UTC while some forms in the backend will be in local time. That's how it has been for years and it works well, so no changes are needed there.

Thanks,

Scott

 

You must be logged in to post in the forum