Timezone Issue to be fixed for changes in SNC
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎04-24-2025 08:08 AM
We have users with multiple locations like China ,Hamburg, India etc., when user table is updated for the users with their respective time zone and my system default is US/Eastern.
Issue is:
The users preference setting is changing to system default as US/Eastern rather than taking user record preference. When updating in Preference-Display to their time zone.
Can anyone suggest how we can resolve this?

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎04-24-2025 06:13 PM
Hi
Unfortunately I dont quite understand your problem. Could you re-explain
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎04-27-2025 11:06 AM
Thanks for your reply, Let me explain the issue in detail,
Suppose I'm the girl who's sitting in the US and she want to raise a ticket for CST timing. She kept the timing as 22/02 10:30 and the timizone she mentioned as CST. Now i'm in india where my profile timezone is IST but my start date and end date will modified to the IST timings but the timezone is CST. Now i'm the person who's performing the activity I will see the ticket planned start date and end date is planned in the timezone of CST but my profile is IST.
Suppose i'm the girl who is sitting in china then start and end date will be china location and timezone is CST. So for the person who is implementing definitely she won't go to profile and she won't see anything, she just see what is the CST timing so this time i have to do the activity. So whomever maybe the profile whoever modified ,the CST timing should be freeze, it should not modified according to the timezone. Even if the profile is irresponsible to SNC we should not consider the profile timing we have to consider only who is the implementor raised timing that timing should be visible for whole world.
Can you suggest how we can resolve this?
Thanks in advance.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎04-27-2025 11:10 AM
Thanks for your reply. Let me explain the issue in detail
Suppose I'm the girl who's sitting in the US and she want to raise a ticket for CST timing. SHe kept the timing as 22/02 10:30 and the timizone she mentioned as CST. Now i'm in india where my profile timezone is IST but my start date and end date will modified to the IST timings but the timezone is CST. Now i'm the person who's performing the activity I will see the ticket planned start date and end date is planned in the timezone of CST but my profile is IST.
Suppose i'm the girl who is sitting in china then start and end date will be china location and timezone is CST. So for the person who is implementing definitely she won't go to profile and she won't see anything, he just see what is the CST timing so this time i have to do the activity. So whomever maybe the profile whoever modified ,the CST timing should be freeze, it should not modified according to the timezone. Even if the profile is irresponsible to SNC we should not consider the profile timing we have to consider only who is the implementor raised timing that timing should be visible for whole world.
Can you suggest how we can resolve this?
Thanks in advance

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎04-28-2025 02:58 AM
Date-time fields are already localised based on the viewing user's timezone preference. It sounds like you're trying to work around this, but you won't be able to change field behaviour.
Instead, you could use a field level message to show the time calculated based on the timezone value on your change request. The user would still need to enter time based on their timezone, but the field message could help by updating the field message as the value changes.
Although, this customisation sounds like possible further confusion will be added.