ServiceDesk

I'm seeing an issue with the start date on incidents since Sunday.  In the database, the process start time is correct.  In the process view page, the start time is an hour early, and in reports (like my open tickets) the start time is two hours early.  So if a ticket is created at 15:20, it shows up as being created at 14:20 in the process view page, and 13:20 in the reports.  I have tried restarting IIS and the server extensions, but it hasn't helped.  It sure looks like a DST bug to me.  I came across this post, and it looks like other people have seen this before.  Is anyone else seeing this?  Is there a workaround, or will this go away?  I have checked the time on the SQL and ServiceDesk servers, and they are correct.  This is happening on both our test and production servers.  SD 7.1 SP2.

 https://www-secure.symantec.com/connect/forums/daylight-savings-time-behind-1-one-hour-servicedesk-71-mr1

i am seeing the exact same problem.

Service Desk 7.1 SP1

Version: ServiceDesk 7.1 SP2

Issue: ServiceDesk web portal displaying time 1 hour behind.

Created a ticket this morning at 8:21 AM, Date Opened on the Tickets tab shows 6:21 AM and the ticket in the Process View report shows 7:21 AM. I checked the time and date on the Service Desk server and it's correct.  I opened up a case with Symantec so hopefully they have a fix for this.

I opened a case on Monday and they are still working on it.  Now that others are noticing the issue hopefully it will be resolved soon.

Still having the issue.

Not yet.  I was informed yesterday that it was finally escalated.  Hopefully before the day is over....

They told me that their advance team is working on it and will provide an update on Monday.

I look forward to what they have to say.

The users you are seeing with (looking at reports, submitting) are all in the same timezone as the SQL and SD server? If not, does the behaviour change at all depending on user's timezone?

Both the SD and the SQL server are in the same time zone.

Found out that all my users are set to"Select Time Zone Dynamically" and the Time Zone is Baja California but should be Pacific Time.  Once I set this to Pacific, things look good.  The only problem is EVERY user is set incorrectly.

Below is a screenshoot from Admin, User, Accounts, Manage Users

When I make the change to Pacific it fixes my process views, but the reports (My Task Viewer) are still off by an hour.

Looks like mine is correct.

Are all your users in the same time zone?

Yes they are

TECH166190 ServiceDesk sets a wrong timezone for user while the time is correct.
http://www.symantec.com/docs/TECH166190

TECH142308 Time stamps in a ticket are showing up in the wrong time zone
http://www.symantec.com/docs/TECH142308

This is the core of how timezone detection (which is enabled by default) works:

This is useful, but the second article is out of date.  By manually changing the timezone and restarting IIS, all of the dates are correct now, but I don't see any way to set the default timezone for the AD sync.  So any new users that get synced will have the wrong timezone.  In the TECH142308 article, it says to go in to Admin -> AD servers, edit the server, and set the AD server timezone.  We don't have that option in 7.1 SP2.  How do I set the timezone, so I don't have to do this for every new user?

7.1 SP1 looks to be the same as SP2.  I would also like a global change as well.

Are all your users in the same time zone? Our users are in multiple time zones and there's no way I want to manually go in and adjust time zones for each individual as that would too time consuming. The time in the reports were working before DST and Symantec is aware of this issue so there should be another workaround. 

Got an update from Support and this seemed to fix the issue for me. I didn't have to make any changes to the user's time zone.

1. Under Admin/Portal/Master Settings - Process Manager Settings - Display time in local time Zone, disable this

I had to make the change to the user's time zones and in the Process Manager Settings.  Now working.

...thanks!