Hello,
I’ve just noticed that the date field after “waiting for reminder” seems to be in the wrong format. All other dates are displayed correctly. Am I missing something?
Thanks in advance!
Date format dd.mm.yyyy
mm/ddd/yyyy
Hello,
i have the same Bug after Update from 4.1 to 5.1… Have you any solution?
Thanks
Update to the latest possible Version and check again. I cannot verify this on a current instance version.
Possibly has been fixed in the mean time.
Using version 5.2.1 on Debian I have the same issue with the Pending Reminder field although only in the ticket itself.
If I look at the overview the date format is correct (UK date format)
If I open the ticket the date format is wrong (US format)
We are using the newest Version, but the Bug still has not been fixed…
I see this behavior too on 2 different systems. Both with current version 5.2.2
We have updated to 5.2.2 (-1664451892.bca42243.buster), but the behavior is still the same. As nanathlor has mentioned, it’s only in the ticket itself, everywhere else the dates are displayed correctly.
Is date-picker (“js-timepicker”) maybe causing the Problem?
What locale is set in your browser?
Doesn’t happen to be EN / EN-US? ^^
I’m unable to reproduce this.
Even with explicitly setting the “preferred language for websites” to en-us.
Make sure that you don’t have custom translations active.
I have the same problem but not only with the field “Waiting for customer” but also with other fields where a date has to be stored in a ticket.I have tested the whole thing on several browsers and everywhere the wrong format is output.
Currently we are using Version 5.2.x and plan to update to Version 5.3.x in January.
Is it possible that this bug only occurs with self-hosted Zammad servers? On a non-self-hosted Zammad server, the date is correct. Again, I am using the same browser.
Hosted by Zammad:
Self-hosted:
No that shouldn’t be that specific on that regard.
Make sure you compare the same versions, SaaS is on 5.3 and the version I’ve tested is as well.
I’m not verifying older versions as they’re out of support anyway.
Let’s see what happens with your update then.
I have the same problem in Version 5.3.1. with self-hosted Zammad Server
Alright.
I guess you’re all using german as translation, if not, you’ll have to update the locale to yours (Locale.pluck(:name, :locale))
Now you’ll run this command to see if the affected source has more than one result:
Translation.where(locale: 'de-de', source: 'FORMAT_DATETIME').count
If the return is 2 or higher, run this:
pp Translation.where(locale: 'de-de', source: 'FORMAT_DATETIME')
and share it with us here.
All above commands are rails commands - here’s how to run those commands: Console — Zammad documentation
We noticed the same issue on our side after upgrading to 5.3.1.
There was one entry for FORMAT_DATETIME (in de-de), but none for FORMAT_DATE.
Running Translation.sync synced all translations to the database. We went from ~1.7k to ~151k rows.
Afterwards we got entries for FORMAT_DATE and the UI showed the correctly formatted date.
(Also a different environment of ours running the same version had ~3.1k rows).
Not sure how many entries are expected to be in the database.
Previous version was 5.2.3, but the database state was probably even older, as we had one failing migration script (20220124141828_overview_updates.rb, because some of our default overviews did not have roles assigned). With the update to 5.3.1 Zammad crashed and we noticed the failing script, fixed the issue and ran all pending migrations.
Wow Joschasa, THANK YOU! I have now finally been able to “fix” this problem, after what feels like forever!
I truncated the translations table and ran the Locale.sync command and what do you know, the date is now being displayed correctly. It seems I also had the upgrade problem, I do remember, I once got a SQL error message to do with the translations (duplicate id 66841, FEHLER: doppelter Schlüsselwert verletzt Unique-Constraint »translations_pkey«).
This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.
