To be clear: my problem here is not "it doesn't works with this concrete string", but rather "it doesn't work with a string it returned itself".

I vaguely recall a peculiarity in MRI that the 9-argument form of Time.mktime ignores zone. This may have been an oversight they fixed.

FWIW, it doesn't work in CDT either:

[] ~/projects/jruby $ jruby blah.rb
2016-07-11 18:31:24 -0500
"CDT"
2016-07-11 18:31:24 UTC
"UTC"

[] ~/projects/jruby $ ruby23 blah.rb
2016-07-11 18:31:29 -0500
"CDT"
2016-07-11 18:31:29 -0500
"CDT"

Hmm...we do appear to be looking at the timezone, but it doesn't appear to get set correctly.

Ok, looks like this is in the group of timezones that Joda Time does not support (because they are considered nonstandard):

java.lang.IllegalArgumentException: The datetime zone id 'CDT' is not recognised
    at org.joda.time.DateTimeZone.forID(DateTimeZone.java:229)
    at org.jruby.RubyTime.parseTZString(RubyTime.java:208)
    at org.jruby.RubyTime.parseZoneString(RubyTime.java:230)
    at org.jruby.RubyTime.getTimeZoneFromString(RubyTime.java:222)
    at org.jruby.RubyTime.createTime(RubyTime.java:1373)
    at org.jruby.RubyTime.new_local(RubyTime.java:1172)
    at org.jruby.RubyTime$INVOKER$s$0$9$new_local.call(RubyTime$INVOKER$s$0$9$new_local.gen)
    at org.jruby.runtime.callsite.CachingCallSite.cacheAndCall(CachingCallSite.java:283)
    at org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:69)
    at blah.invokeOther12:mktime(blah.rb:6)
    at blah.RUBY$script(blah.rb:6)

I believe there's a way to get a time zone from Joda using these legacy abbreviations. If not, we may want to do a fallback to JDK's timezone logic, which I believe supports them.

FWIW a quick workaround would probably be for you to use the full canonical name of an appropriate EEST city as your TZ environment. Joda Time prefers that daylight savings is calculated rather than set or forced, which is why it doesn't have support for most of the DST-related timezone abbreviations.

I'm testing a fallback to JDK timezone support.

Ok, the JDK classes don't appear to support these older abbreviations either, and it's likely because they were never standardized and have a number of duplicates: https://en.wikipedia.org/wiki/List_of_time_zone_abbreviations

At the moment it seems your best option is using a specific, canonical time zone "country/city" identifier as your timezone rather than EEST or EEDT. Every resources I can find basically says these older abbreviations should not be used anymore.

Hey, thanks for investigation.
Unfortunately, using full timezone name is not an option for me: in my time_math2 gem I need to preserve source time's zone -- and that's the only thing I know (and exactly what I've showed in the first comment): having t1 in some zone, I need to produce some f(t1) and be sure it is still in same zone. In several cases this means I break t1 into components (year, month, day ...), adjust them, and construct f(t1) from adjusted components.

Currently, I use fallback to UTC offsets to handle this problem JRuby, but it will not work correctly on DST boundaries.

Yeah I think our only option here is to find a translation table from "established" short abbreviations to their long form equivalents.

OK, I was wrong. After further investigation, this ..., t.zone) parameter is ignored silently on MRI, I just was lucky to be in same timezone I've tested. It is still difference in behaviors between JRuby and MRI (JRuby does UTC in this case, while MRI does localtime), but not that bad I've reported initially.

Thanks for following up on this. I wish there were a better option for those old-style time zones.

Working on it! (That's how I've found I was wrong previously) :)