Shorter reproduction:

$ bin/jruby -e "Gem.activate_bin_path('bundler', 'bundle', '1.16.2'); \
                require 'bundler'; \
                Bundler.load_gemspec_uncached('/tmp/foo.gemspec')"

No Gemfile needed.

The next reproduction, excluding more code, would be

$ bin/jruby -e "Gem.activate_bin_path('bundler', 'bundle', '1.16.2'); \
               require 'bundler'; \
               Bundler::SharedHelpers.chdir('/tmp') { \
                 Bundler.send(:eval_gemspec, \
                                       Pathname.new('/tmp/foo.gemspec'), \
                                       %(Time.now.strftime('%Y-%m-%d')\n))}"

but that doesn't reproduce the issue anymore.

wanted to look into this but (yet) seems Bundler 1.16.2 specific ... which must be a recent release 😞

bin/jruby -e "Gem.activate_bin_path('bundler', 'bundle', '1.16.1'); \
                require 'bundler'; \
                Bundler.load_gemspec_uncached('./foo.gemspec')"

NoMethodError: undefined method `loaded_from=' for "2018-05-21":String
  load_gemspec_uncached at /home/kares/workspace/oss/jruby/lib/ruby/gems/shared/gems/bundler-1.16.1/lib/bundler.rb:441
                 <main> at -e:1

Problem turns out to be independent of bundler. Smaller reproduction:

bin/jruby -e "eval File.read('/tmp/foo.rb', mode: 'rb')"

where foo.rb contains the aforementioned Time.now.strftime('%Y-%m-%d'). Replacing 'rb' by 'r' makes the error go away. Replacing 'rb' by 'r:ASCII-8BIT' reproduces the error. Replacing 'rb' by 'r:UTF-8' reproduces the error. Removing the eval makes the error go away.

Passes on JRuby 9.1.17.0.

A quick glance and some notes. default will be UTF-8 for eval and that works and so does even more uncommon encodings which are ascii compatible like EUC-JP. If I force_encoding of the format string I can see that we also work. So ASCII-BINARY strftime format string is our problem. Reduced more:

Time.now.strftime('%Y-%m-%d'.force_encoding('ASCII-8BIT'))

The following patch fixes it. Without calling into this line, the Format class never initializes properly, which leaves the conversion token mapping array unpopulated, so all tokens come out null.

This isn't the right fix; the Format enumeration needs to be allowed to initialize properly before the parsing proceeds. It doesn't without this code because all subsequent logic goes directly for the conversion array, which doesn't trigger the class initialization.

diff --git a/core/src/main/java/org/jruby/util/RubyDateFormatter.java b/core/src/main/java/org/jruby/util/RubyDateFormatter.java
index fb9618e086..dc1193dee0 100644
--- a/core/src/main/java/org/jruby/util/RubyDateFormatter.java
+++ b/core/src/main/java/org/jruby/util/RubyDateFormatter.java
@@ -266,9 +266,9 @@ public class RubyDateFormatter {
         }
 
         final List<Token> compiledPattern = new LinkedList<Token>();
-        if (enc != ASCIIEncoding.INSTANCE) { // default for ByteList
+//        if (enc != ASCIIEncoding.INSTANCE) { // default for ByteList
             compiledPattern.add(new Token(Format.FORMAT_ENCODING, enc));
-        }
+//        }
 
         ByteArrayInputStream in = new ByteArrayInputStream(pattern.getUnsafeBytes(), pattern.getBegin(), pattern.getRealSize());
         Reader reader = new InputStreamReader(in, runtime.getEncodingService().charsetForEncoding(pattern.getEncoding()));

The bug was introduced at 7b8221e by commenting out an access of one of the Format enum values. This forced the class, and the associated conversion array, to be initialized.

I have a more complete fix in process.