Problem with Russian Win7

[Johnsik]

Problem with Russian Win7

[mojavelinux]

Yes, this is a known issue we're going to have to tackle. In an effort to get a minimum viable implementation, we mapped the regular expressions in Ruby to simplistic ones in JavaScript. The regexp engine in JavaScript is quite primitive...even more so than the Ruby 1.8.7 engine the Asciidoctor regexps adhere to.

You can see the mapping from Ruby regexp to JavaScript regexp here:

https://github.com/asciidoctor/asciidoctor/blob/master/lib/asciidoctor.rb#L344

...there are some other places as well, but these are the majority of them.

The following article describes what we're going to need to do to get proper support for non-English languages.

http://mathiasbynens.be/notes/javascript-unicode

[Johnsik]

It's greate plan!
But as a interim solution I propose change from "%H:%M:%S %Z" to "%H:%M:%S" in asciidoctor.js:2740
It's works and no any problem with Win7 Rus.

[mojavelinux]

Yep, we can put that in. However, it needs to go upstream into Asciidoctor
core since Asciidoctor.js is now 100% generated.

[Johnsik]

May be better to change opal.js instead?
To return empty zone name.

[mojavelinux]

Could you paste a datetime string as it appears in win7 russian so I have an example to work with?

[mojavelinux]

I took a slightly different approach, but essentially the same implementation. I drop the timezone if it fails to resolve using a try/catch block.

[mojavelinux]

I'm still interested in the test date so I can sort out how to make a test for this case. I'm actually curious whether Ruby has a problem with this as well...but I haven't been able to figure out how to get Ruby to emit a timezone in Russian.

[Johnsik]

try/catch is good idea.

Thu Mar 06 2014 12:52:51 GMT+0400 (Московское время (зима))

[mojavelinux]

For the record, here's an example:

Чт июл  7 08:06:41 МСК 2016

In order to reproduce, the JavaScript implementation has to produce this result when calling new Date().toString() since the conversion happens in the internals of the Time class.

[mojavelinux]

Opal should probably use toLocaleDateString() (and/or toLocaleTimeString()) instead of toString() so that it gets a consistent result to parse. After all, this is all internal state.

[mojavelinux]

Actually, that turns out to be not all that reliable. Whatever the solution, I think Opal should not be assuming that toString() is going to be in the en-US locale.