What is UTC?
UTC is Coordinated Universal Time. To us that is the same as GMT or Greenwich Mean Time. It is a way of referring to a time in a common way starting at a small town in England. Makes perfect sense right?
Why UTC?
So in SalesLogix the problem with timezones happens when you have one person from the east coast of the US updating data and another person on the west coast updating data at the “same time”. Lets say they both do it right now. It is early in the morning West Coast (not really but that is when this post is to be published). On the east coast the database will say something like 10am and on the west coast something like 7am. Then we both sync to the database (assuming your remotes change the clock on their laptop when traveling). The person on the west coast will probably have their overwritten because they happened “earlier” than the east coast person. This is true for the next 3 hours! Obviously we cannot have this and in version 6.2.? the upgrade process made everything in the database UTC (or universally the same time).
This means every time that is placed into the database needs to be in UTC time right? So we need to convert the time from our timezone to UTC before saving right? No. Not in the LAN. You guys know this. Do you know why?
Why not in the Lan?
The LAN sends everything through the provider right? That magical SalesLogix Provider. Referred to as SLXOLEDB.1 by developers and as an object on every server and workstation by administrators/implementers. When the change was made in 6.2.? (I was not around) the provider was written to take the time submitted by the user, the time on the machine it is on, and calculate UTC automatically for us. So we have not had to worry about it.
When remotes sync, they sync in UTC, when LAN users save data they save through the provider in UTC. Developers on the LAN have lived in an easy world.
How is it done in the Web?
Well in the web we still need to convert everything to UTC. Why? Because we said so.
Well in the lan you could just set a datetime field how you saw fit and it would be handled for you.
In the web you need to work with:
DateTime.UtcNow;
it isn’t a big deal. If you want to save anything with a date or time you just have to ensure that you have converted the date and time to UTC. Using the above code takes the current time and converts it for you.
That is C# or asp.net code. What if you want to do the same in JavaScript or another language? Well you need to find the conversion for that language.
JavaScript version here
How can you tell?
The question remains “Does the web not go through the provider?” and then “Wait! I know it does!” Jason must be wrong.
Well I am wrong a lot, but not in this case I am afraid.
Here is the reason:
a connectionstring from the connectionstring.config on the web (actually Process Host in this case):
Provider=SLXOLEDB.1;Persist Security Info=True;Initial Catalog=SALESLOGIX_EVAL;Data Source=WINDOWS2003BASE;Extended Properties="PORT=1706;LOG=ONSVRCERT=12345;;ACTIVITYSECURITY=OFF;TIMEZONE=NONE"
and one from a UDL file I create for a lan customization or by using Application.ConnectionString:
SLXOLEDB.1;Persist Security Info=True;Password="";User ID=admin;Initial Catalog=SALESLOGIX_EVAL;Data Source=WINDOWS2003BASE;Extended Properties="PORT=1706;LOG=ON"
Notice that last part:
TIMEZONE=NONE
That tells the provider to NOT convert the dates and times to UTC. I am told this is a requirement. I changed my connection.config on a recent build and the site ran just fine, but I have yet to attempt a save of data or anything like that to see if there is an impact.
So Why go back to requiring UTC?
Well the database is still storing the information in UTC format only, so we are not going back to anything there. It is still the “new” way in the db. The reason on the web is that the web server is getting requests from many sources at once. You could have many users from many timezones sending in requests all at once. You cannot tell from the server side what timezone they are in. You can tell from the client and pass that information in, but that would kind of be the same problem wouldn’t it? Having to set a timezone before you could update any dates or times in the database? So remember the code that we are talking about runs at the server. The client (IE, FireFox or Chrome) has no automatic way to pass this information in to the server. Make sense?
