Skip to main content
cancel
Showing results for 
Search instead for 
Did you mean: 
Not applicable

Documentation of converToLocalTime has bugs?

While using the convertToLocalTime method (see documenation: http://help.qlik.com/sense/en-US/online/#../Subsystems/WorkingWith/Content/Scripting/DateAndTimeFunc... ) I found many inconsistencies.

I'm not sure if this is worth a bug ticket, so I first try to get some answers in this discussion:

Broken "places":

Timezone mentioned in Qlik DokuComment
"Greenwich Mean Time : Dublin"does not work, you need to use "Dublin" instead
"Greenland"

There are different timezones in Greenland. This is misleading. You should somehow mention that this is Western Greenland UTC-3 and not Eastern Greenland

"Indiana (East)"Why "east" is there another Indiana?
"Ekaterinburg"This is almost everywhere else written with a "Y" in front of. I. e. "Yekaterinburg"
"La Paz"This is not unique. There are two "La Paz", one in Bolivia with UTC-04:00 and one in Mexico with UTC-07:00. You should mention that this is the mexican version. Very misleading otherwise.
"Mid-Atlantic"There are many countries in this timezone, some have DST some have not. Which one is used here?
"Mountain Time (US & Canada)"There are different DST settings e. g. Phoenix does not have a summer/winter time, but Denver, Calgary, Salt Lake City do change on winter/summer. Which one is used for this timezone?
"St. Petersburg"(a bit misleading, could be Saint Petersburg in Russia or St. Petersburg in Florida. It is Florida, but you probably need to try it to get the correct association).

Is this desired? This looks like guessing what could happen for those specific timezones and hopefully getting the expected results. If you don't double check your timezone setting this could move dates/times to wrong/unexpected values.

0 Replies