Nope.. the timezone setting should not "break" anything... but if you are using CIFS and you clock skew typically 5 mins. off your DC, you will get issues because or kerberos...
#Extremely dumb timezone question
inland flame
Everything goes off of UTC/GMT anyway
In ONTAP, check with
date -u
In windows powershell
(Get-Date).ToUniversalTime()
Compare them. Timezone just make it easier for a human
lunar reef
Yep... but I am pretty sure the event log is show as just a date+time... doesn't it get a bit confused if you modify your TZ? or does the event log... command take case of that?
inland flame
Ah. Log files are generally based on whatever timezone you use!
When we “secure” environments, one of the requirements is to make sure everything is left at UTC/GMT. This is done so that all log files are or should be on equal footing for time correlation. Easier to match up when events occurr
And if you want to use timezone shortcuts and you use daylight savings, you can use (in the USA anyway)
EST5EDT
CST6CDT
MST7MDT
PST8PDT
serene dust
also local (snapshot) schedules go after the configured time zone, i.e. if you do snapshots at 10:00 AM and at 9:50 you change the timezone, and suddenly it's 10:50 for the system, the 10:00 snapshot will be missed
viral shoal
and that was the issue, there is a business process that actually takes data from a scheduled snapshot
the timezone was corrected, but we noticed some of our scheduled jobs are still firing off an hour later, which is strange
the midnight daily snapshot job fired off at 1am
serene dust
depends on where they're triggered: on the ONTAP system itself, on a management host, in SnapCenter, OTV, etc. ...
viral shoal
On the ONTAP system itself
viral shoal
I hope I don't have to recreate and reapply all my schedules in job schedule cron