Giters

basecamp / local_time

Rails engine for cache-friendly, client-side local time

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

i18n timezones are not parsed correctly because of unicode issues or translation issues.

a-nickol opened this issue · comments

commented

Non english timezones, e.g. Fri Dec 29 2023 12:21:08 GMT+0100 (Mitteleuropäische Normalzeit) are not parsed correctly.

First the regex does not work, because 'ä' is no ascii char.
Nevertheless the concatenation of the first letters of the timezone won't work either.

commented

Thanks @a-nickol, could you confirm if it's parsed correctly in this branch, please? It's a work-in-progress PR that's near completion.

commented

The tests work on my machine, yes.

commented

@a-nickol Thanks for checking. Just to make sure, when you say the tests work do you mean running the full automated test suite or did you perform the manual check on localhost:9000 (a new addition in that PR)? Or possibly both?

Only the manual check would've caught any regressions re: your local timezone.

commented

I executed 'rake test' and called the new route. I haven't checked the result or semantics of the route in detail, but more importantly the automatic test suite passed compared to the main branch which fails because of timezone issues.

commented

Ah I see I thought the test suite would pass on main. Perfect, thanks for confirming.

commented

#142 has been merged so this should be fixed on main now. Thanks again.

commented

The tests fail now, e.g.

strftime time zones: time zones Intl can't abbreviate are parsed by our heuristic
'GMT+7' doesn't look like a timezone. System date: 'Sat Dec 02 2023 11:32:44 GMT+0100 (Mitteleuropäische Normalzeit)'
commented

@a-nickol Ah, that's from a new test that actually might not be worth keeping around. I'll take a look today. If you don't mind, could you share which country you're in and which language you're using in your browser? Thanks!

commented

Also, please let me know if any other tests fail as well.

commented

I am in Germany, language is German. We have currently winter time, this is CET.

commented

Every second execution all timezone tests are failing because GMT+7 is not accepted by the timezone assertions. Maybe a mock or stub is not restored.

Later I have maybe time to check, too.

I think it is because the one test fails, thus the stub is not restored because of the corresponding exception.

commented

@josefarias stub.restore() is missing on test/javascripts/src/strftime_test.coffee:107

commented

The mock sets the data accordingly which used later and then fails:

      if options.timeZoneName == "long"
        "Thu Nov 30 2023 14:22:57 GMT+0700 (Central Twilight Time)" # not a known edge-case
      else if options.timeZoneName == "short"
        "11/30/2023, 2:22:57 PM GMT+7" # not possible to abbreviate

Error:

'GMT+7' doesn't look like a timezone.
commented

Thanks @a-nickol, great digging. The root cause was that we weren't completely stubbing the current timezone in the failing test. Should be fixed by #154, so tests should be passing for you on main once merged.

Maybe a mock or stub is not restored.

Right, the tests were fragile in this regard. I've also gone ahead and improved that in the same PR.