Weird date bug - date gets registered as one day before what I input


I have the weirdest bug and I don’t know where to start from to debug it.
When I input a date metadata, then the date is saved as one day before what I input (example 20/10/2020 becomes 19/10/2020). This happens both when I create a new item, and when I edit the date metadata of an existing item.

Thanks for the help

Same here :joy:

hmm, it might have something to do with timezones then? perhaps the date is not just a date but a date+time in the backend?

Hey hey hey @Alkis and @adrian. I’ve bumped into this last year as well, it’s annoying…

Yes, that is the right guess. Timezones may cause the day to be added/suppressed. I’ll do some tests here and send a compiled version for you to try. Maybe something related to our moment.js bundle, we don’t add every possible locale to keep it lighter.

Here you go @adrian

Did something really simple, not sure if it will do the trick… if it doesn’t, let me know, I’ll have to investigate more.

Hey, thanks you so much for the quick fix.
I tried it but it doesn’t fix the problem - same bug as before, date gets registered as one day before what I input

Yeaaah it would be too good to be true :sweat_smile:

No problem, I’ve opened an issue to take a look then:

@adrian, been doing some tests here it is a bit mysterious…

Could you please:

  1. Confirm that your browser language is set to el? The interface should be greek, obviously, and if you type navigator.language in the console it should result el.
  2. Could you tell me how is your WordPress data format settings done? You should be able to check it under your Admin Panel → Settings → General → Date Format;

That can help me test here :slight_smile:

Hello @mateus.m.luna

By browser is actually set to en-US . System language is also English (Fedora, if that is important), and the system time zone is EET (Athens) (GMT +2/+3).

My Wordpress date format settings are:
Timezone Europe/Athens ( Universal time 2021-11-23 15:10:55 . local time 2021-11-23 17:10:55 .)
Date format 23/11/2021 d/m/Y
Time format 18:10 H:i
Wordpress’ interface language is set to Greek.

Thanks @adrian. I still wasn’t able to reproduce but I think we are getting closer… here we go, another try:

While testing, please make sure to reload your browser for preventing cache files, probably CTRL+SHIFT+R should to the trick.

We’ll wait for your feedback.

Hey @mateus.m.luna
The problem has been fixed! Thanks a lot for the effort and quick reaction.

What was the problem after all? I was trying to do some debugging myself, but I couldn’t find where/how the item data are saved in the database

1 Like

Yaayyyy :tada: :tada: :tada:

Man, date and timezones are one of the most messy things to work with :no_mouth:. To summarize:

  1. We had to add Greek to our available locations of the moment.js: As I mentioned before, this is needed because we don’t bundle every location information with the plugin, they can be a heavy asset and so far we don’t have users all around the World. But that wasn’t the cause of the issue, it would just fallback to English in your case.
  2. The dates are always saved on the database in a ISO_8601, that is YYYY-MM-DD. We only change it while displaying (for that, metadata have a view_as_html attribute that in this case uses WordPress format settings, you can see it here).
  3. BUT we also have to change it in the metadatum input, and that’s where the issue happened. The input was decreasing a day because it was creating a Data object during the conversion that used the date values provided, such as 20/10/2020. When creating such object, the instance was not handling well the timezone, because its value would be decreased three hours (as your timezone offset is positive, the very beginning of your day is a day already past in the Greenwich - 20/10/2020T00:00:00 - 03:00:00 = 19/10/2020T21:00:00 :exploding_head:). We never noticed that because here in Brazil three hours added won’t change our day :sweat_smile:. Luckily, after some investigation with @vnmedeiros we found that the function toISOString() that we use to generate the data string has a parameter keepOffset, which avoids adjusting the hours to Greenwich. Soooo it was as simple as passing true to this function when we needed it:

That was fun, hope to have solved it for real. In any case, I believe we have a release ready for next week or the one after it. Thanks for the report, that’s the kind of thing that we would never find out!


Thanks again for the work and the solution!

1 Like

I reverted the plugin update because it messed up my photo collection (ONLY ON POLAROID VIEW).


I tried this out of curiosity - Polaroid view mode doesnt break for me.

Yo @Alkis would you mind opening another topic for this? It helps us keep tracks of things.