The above code is supposed to get the day of the week according to the local TimeZone.
Well, in several user locations (Pacific and East Coast Regions), it returns 4 (Wednesday) as
the current day of the week…And, today is Tuesday…
Must be a ST platform issue…
de31fea9-39cf-4a4b-a625-a6b0492a4695 9:53:47 PM: trace IsRightDayForChange>currentDayOfWeek=4 vs. dayOfWeek from Schedule 5=Wednesday
de31fea9-39cf-4a4b-a625-a6b0492a4695 9:53:47 PM: trace IsRightDayForChange>currentDayOfWeek=4, makeChange=false
de31fea9-39cf-4a4b-a625-a6b0492a4695 9:53:47 PM: trace IsRightDayForChange>currentDayOfWeek=4 vs. dayOfWeek from Schedule 4=Tuesday
Have you seen this issue elsewhere??? Has there been any change in the platform lately about the TimeZone processing?
Yeah, but the simpler way to get the right Day of the Week without any need to offset the date timestamp is
String currentDay = new Date().format("E", location.timeZone)
This will work under the ST platform. My point was that any call to Calendar.getInstance(TimeZone.getDefault()) will not work anymore. It used to work but something has changed in the ST platform and it doesn’t handle well the Calendar operations anymore in the local TimeZone.
I won’t pretend to be an expert in working with dates/timezones, other than to know they are difficult, but wouldn’t using TimeZone.getDefault() be prone to errors? TimeZone.getDefault() will get the time zone of the server it is being executed on, which could be different than the time zone of the actual user’s location. And since the server’s time zone isn’t guaranteed to be the same as the time zone of the user’s location, that could lead to issues, I would think.