I bumped into a weird issue this week that I haven’t experienced before.
I use the YYYY-MM-DD format in our docs and starting from this week the cross-doc actions we use (add/modify rows) started to mix up the MM and DD values resulting different dates in the target doc than in the source doc.
I tested this out to see when it would happen and the only way I can make it happen is if I paste values to the date column in the form of “DD-MM-YYYY” when the date column format is set to “YYYY-MM-DD”. This seems to happen with copy/paste and possibly writing a value to the column with a button.
Coda generally works off of a default date format of “MM-DD-YYYY”, so when choosing from the date picker, you’re date values will be in this form in the underlying cell without the column type re-styling them to your chosen format. You can create a column next to your date column and use the ToText() formula to see if anything is being entered in a different format. There’s a chance some values are being pasted/written in and others are being edited with the date picker.
When you push a button in the source doc it adds a new row to the target table inserting the source row’s “Date” column content to the target row’s “Date” column. Both “Date” columns have the same YYYY-MM-DD date format and cross-doc action looks like this:
In theory I think this setup should work (and I think this setup actually worked fine until last week) but right now it’s very confusing and breaks the workflow.
I added the ToText() column to the source table as you suggested. Then I created a cross-doc action button (the yellow ones) that use the ToText() dates instead of the original date picker column values but the result is the same mixed-up date format in the target table…
@BenLee here is another twist. The bug happens only when the DD values are lower than 13 in the original YYYY-MM-DD format.
So if the DD values can be converted to valid MM values (01-12) than the cross-doc action mixes them up. If the DD value is higher than 12 the cross-doc action works fine.
I think this is why my workflows ran correctly for me at the end of last month when I tested them and turned out to be buggy this week
You can test these examples in the source/target docs I published above:
2020-06-12 -> 2020-12-06
2020-06-13 -> 2020-06-13
Same issue here, can’t send a date in by a cross doc add row without getting it inverted. Any news? Last post on this was on june. I’ve already reported it as a bug, but is really critical and it’s generating errors in many rows of information. Help.
It’s been reported then (10 months ago) and they recomend a (really weak) workaround. I hit the matter again today and this way of patching it doesn’t deliver in this case. Anyway, It would be great to count on this forum to get answers without the need of the individual interaction.
I’ve edited and added jpg of what they said back then. I mean…
