Summer/Winter time change

[xaxa_1]

Hello

I work on a project in Russia where there were winter time (GMT+3) and summer time (GMT+4). But  now due to government order there will be no such time shifts anymore and they will stay in summer time from now on.

In order for SM to deal with it properly, is it enough for me to remove all future shift dates (field "switchover" from table "tzfile") in "Russia/Moscow", "Russia/Vladivostok", etc?

Points for replies!

[Vadim Gorda]

Hello,

Yes it must be enough. Leave only one setting of time for the offset from GMT (I mean 1 line in the Time change definition array inside the tzfile record for your timezone).

[xaxa_1]

Hi, Vadim!

Thanks for the reply, but let me understand -

in tzfile for "Russia/Moscow" in "converstion.type" field I have:

MSK          03:00:00

MSK1        04:00:00

do you mean I should delete the first line here? Won't it affect all tickets that were opened in previous years?

Would it be enough just to delete all lines from "switchover" field which correspond to future dates, like

10/30/11 03:00:00       0

03/25/12 02:00:00       1

10/28/12 03:00:00       0

....

[Vadim Gorda]

Hello,

I dont think that it will affect anything in past.

There is even nothing like update of the contact name down to the related objects (Interactions, Incidents ... ) if you change his name in the contact table (we all love non relational db :))))))).

You can delete the switchovers and it wont switch in future any more but at the same time you should not be afraid of removing the time ofset in the first column as it should not affect anything as well.

[RobertWil · Accepted solution]

You should remove future lines from switchover array to achieve your goal.

DO NOT remove lines from conversion.type array - you will get many error messages:
Errors occurred converting timezone record, check the HP Service Manager log for details. (calendar.calc.interval,get.switchovers)
additionally all dates from deleted "offset" will be affected!
(or all of them if you move second one to first position)

To make things clear, it would affect representation/display of dates (dates in database won't change, they are stored as UTC)