11/25/2024 4:38:29 AM
|
| |
| slxdeveloper.com Community Forums |
|
| |
|
|
The Forums on slxdeveloper.com are now retired. The forum archive will remain available for the time being. Thank you for your participation on slxdeveloper.com!
Forum to discuss networking and miscelleanous technical topics. View the code of conduct for posting guidelines.
|
|
|
|
6.2 and Time Zones...
Posted: 02 Nov 06 3:33 PM
|
fiogf49gjkf0d Hi,
We are having a discussion where I work about how SalesLogix implements the new Time Zone functionality in v6.2. The way I see it is that it provides a list of time zones by referencing the time zones in the registry and stores the tz selected in the UserInfo table. Then uses that field to find any offsets for meetings and other dependencies on the time. If that is the case, then it shouldn't matter if the user is logging in via Citrix because the value is store in a table. Is that correct?
Thanks.
Terry
|
|
|
|
Re: 6.2 and Time Zones...
Posted: 03 Nov 06 7:41 AM
|
fiogf49gjkf0d As far as I know the timezone field in the userinfo table is only used when upgrading an existing database to 6.2.
All datetime values are stored as GMT value. SalesLogix querys the local PC to determine the timezone setting and uses this to calculate the offset to be applied to datetime values. For example if a user in EST schedules a meeting for 8:00am on Dec 1 2006 the value stored in the database will be 1pm on Dec 1 2006. When a user in CST views the meeting they see it scheduled for 7am.
If a Citrix Server is servicing users in multiple timezones the user's timezone needs to be stored in the user's profile, or Citrix needs to be configured to acquire the user's timezone informaiton from the user's local settings. |
|
|
|
Re: 6.2 and Time Zones...
Posted: 03 Nov 06 8:16 AM
|
fiogf49gjkf0d We have found in our citrix environment that the time zone offset is based on the local client machine. In our test lab we were able to test multi-time zone functionality as we were having problems after our upgrade to 6.2.3 we did this by changing the time zone in windows on the client in other words the time was machine specific.
The one problem we saw was that after our conversion user on the west coast were seeing dates converted to the day before, the cause was how the field was built. We needed just date and it was date/time this was causing the day to fall back for our west coast users when user had entered data in the east early in the morning or were overseas once we changed the field to just a date it worked perfectly. ML 
|
|
|
|
You can
subscribe to receive a daily forum digest in your
user profile. View the site code
of conduct for posting guidelines.
 Forum RSS Feed - Subscribe to the forum RSS feed to keep on top of the latest forum activity!
|
|
|
|
|
|
|
|