How to convert date time value in GMT to value in a specific time zone

Whereas the gmt() function converts a given date into its GMT equivalent, I think you might be interested more in local(), which does essentially the opposite.

The local function could also be used. However, the gmt function is a date and time subtraction function: The function converts its second parameter, the timezone offset in minutes, to an interval, and subtracts it from the first parameter, the base date and time.

I'm a little unclear on how that helps in this use case, though - it sounds like the original poster is starting with a GMT database value and wants to show it translated to a named time zone -- the description of the functionality of gmt() sounds like it inherently does the opposite of that.

Yes, Mike. You are right. I want a opposite of gmt().

I can't use the local() because I want to convert to a named timezone, not the timezone in user setting.

local() accepts a time zone parameter, though.  Is this not working for you?

Good point. the local and gmt functions are opposite of each other, local *adds* a named timezone interval to the base date and time -- gmt *subtracts* a named timezone interval from the base date and time. I think what works best for you may depend on your use case, and I'm not clear on what the full use case or user story is here. 

I look for a ConvertTimeFromGMT function that:

ConvertTimeFromGMT(datetime(2020,03,24,11,0,0,0)", "America/New_York") returns 2020-03-24 7:00 AM. 

Because 11 AM in GMT is 7 AM New York Time.

Both local(datetime(2020,03,24,11,0,0,0)", "America/New_York") and gmt(datetime(2020,03,24,11,0,0,0)", "America/New_York") does not give me that expected result.

This is tricky - when you run "datetime(2020,03,24,11,0,0)", i.e. from the expression rule editor, it interprets the resulting value already converted to your user preferred time zone, so then running local() on that result generates an incorrect value.  AFAIK this will behave differently if you run it directly on a value pulled from the DB.  Also I find that using the function "userdatetime()" in the expression rule editor causes more expected values to be shown.

All of this depends pretty largely on your particular use case, and overall data source and format -- all I can say is that you should experiment in the expression rule editor with what different things cause different outputs, because I guarantee there's a way to get what you want, even if it's a little confusing to get there.

This is tricky - when you run "datetime(2020,03,24,11,0,0)", i.e. from the expression rule editor, it interprets the resulting value already converted to your user preferred time zone, so then running local() on that result generates an incorrect value.  AFAIK this will behave differently if you run it directly on a value pulled from the DB.  Also I find that using the function "userdatetime()" in the expression rule editor causes more expected values to be shown.

All of this depends pretty largely on your particular use case, and overall data source and format -- all I can say is that you should experiment in the expression rule editor with what different things cause different outputs, because I guarantee there's a way to get what you want, even if it's a little confusing to get there.

userdatetime() function did the trick. Thanks Mike

cool - in the mean time i submit that it might behave differently in a running process (for example) than it behaves for you in the expression editor, so depending on how you plan to use it, i suggest you test in advance.

thanks Mike for your warning.