Date Format after "waiting for reminder" is wrong format

Infos:

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!

  • Used Zammad version: 5.1.x
  • Used Zammad installation type: package, docker-compose
  • Operating system: Debian 4.19
  • Browser + version: Firefox 98.0.2

Expected behavior:

Date format dd.mm.yyyy

Actual behavior:

mm/ddd/yyyy

grafik

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…

grafik

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?

grafik

What locale is set in your browser?
Doesn’t happen to be EN / EN-US? ^^

afraid not.

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:

image

Self-hosted:

image

image

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.

1 Like

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«).