AppFlowy-IO/AppFlowy

Fork 0

mirror of https://github.com/AppFlowy-IO/AppFlowy.git synced 2026-03-24 12:56:59 +00:00

1970 on larger files #3864

New issue

Closed

opened 2026-03-23 21:33:41 +00:00 by mirror · 5 comments

mirror commented

2026-03-23 21:33:41 +00:00

Owner

Originally created by @twinstef on GitHub (Feb 1, 2026).
Original GitHub issue: https://github.com/AppFlowy-IO/AppFlowy/issues/8467

Originally assigned to: @appflowy on GitHub.

Bug Description

Summary
When importing a CSV file with a Date column into AppFlowy , date parsing fails and all dates are set to 01/01/1970 (Unix epoch) once the file exceeds a certain size.
This happens even when all date values are valid and identical.

S-1-180-minimal-oneDateNoChar.csv

How to Reproduce

Environment

AppFlowy Desktop v 0.11.1 - (tested on Windows 11 and Ubuntu 24.04)
Issue reproducible on both platforms
Issue reproducible on self hosted cloud and on appflowy cloud
CSV import into Grid/Table
Date column type

Actual behavior

For small CSV files (≈20–30 rows), dates import correctly
For larger CSV files (~180 rows):
- All date values are replaced with 01/01/1970
- This happens from the first row
- Other columns (text) import correctly

Key observations

The issue is not caused by invalid data
Reproduced with:
- Valid DD/MM/YYYY dates
- Valid MM/DD/YYYY dates
- ISO formats
- Even with the same valid date repeated on all rows
Splitting the file into smaller chunks (e.g. 30 rows each) works every time
Re-importing AppFlowy’s own exported CSV also fails at scale
On Ubuntu Desktop, the bug occurs even with smaller files

Strong indication
This looks like a threshold-related bug in the CSV import logic (type inference or date parsing), where:

A parsing failure triggers a silent fallback to DateTime.fromMillisecondsSinceEpoch(0)
The fallback is applied globally instead of per-cell
The column is not downgraded to text when parsing fails

Suggested fix

If date parsing fails:
-Do not default to Unix epoch
- Leave the cell empty or keep the original string
If too many parse failures occur:
- Automatically import the column as Text instead of Date
Avoid silent fallback to 01/01/1970

Minimal reproduction

CSV with 2 columns (Date,Place)
-> Start , Localtion
-> 17/04/2025 , Annecy
-> 17/04/2025 , Annecy
-> ...
180 rows
All rows contain the same valid date
Import → all dates become 01/01/1970

Expected Behavior

Valid dates should be imported correctly
If a date cannot be parsed, the cell should be left empty or treated as text
Import should never silently replace values with 01/01/1970

Operating System

Windows 11 + Ubuntu 24.04

AppFlowy Version(s)

0.11.1

Screenshots

Additional Context

No response

Originally created by @twinstef on GitHub (Feb 1, 2026). Original GitHub issue: https://github.com/AppFlowy-IO/AppFlowy/issues/8467 Originally assigned to: @appflowy on GitHub. ### Bug Description Summary When importing a CSV file with a Date column into AppFlowy , date parsing fails and all dates are set to 01/01/1970 (Unix epoch) once the file exceeds a certain size. This happens even when all date values are valid and identical. [S-1-180-minimal-oneDateNoChar.csv](https://github.com/user-attachments/files/24993313/S-1-180-minimal-oneDateNoChar.csv) ### How to Reproduce **Environment** - AppFlowy Desktop v 0.11.1 - (tested on Windows 11 and Ubuntu 24.04) - Issue reproducible on both platforms - Issue reproducible on self hosted cloud and on appflowy cloud - CSV import into Grid/Table - Date column type **Actual behavior** - For small CSV files (≈20–30 rows), dates import correctly - For larger CSV files (~180 rows): - All date values are replaced with 01/01/1970 - This happens from the first row - Other columns (text) import correctly **Key observations** - The issue is not caused by invalid data - Reproduced with: - Valid DD/MM/YYYY dates - Valid MM/DD/YYYY dates - ISO formats - Even with the same valid date repeated on all rows - Splitting the file into smaller chunks (e.g. 30 rows each) works every time - Re-importing AppFlowy’s own exported CSV also fails at scale - On Ubuntu Desktop, the bug occurs even with smaller files **Strong indication** This looks like a threshold-related bug in the CSV import logic (type inference or date parsing), where: - A parsing failure triggers a silent fallback to DateTime.fromMillisecondsSinceEpoch(0) - The fallback is applied globally instead of per-cell - The column is not downgraded to text when parsing fails **Suggested fix** - If date parsing fails: -Do not default to Unix epoch - Leave the cell empty or keep the original string - If too many parse failures occur: - Automatically import the column as Text instead of Date - Avoid silent fallback to 01/01/1970 **Minimal reproduction** - CSV with 2 columns (Date,Place) -> Start , Localtion -> 17/04/2025 , Annecy -> 17/04/2025 , Annecy -> ... - 180 rows - All rows contain the same valid date - Import → all dates become 01/01/1970 ### Expected Behavior Valid dates should be imported correctly If a date cannot be parsed, the cell should be left empty or treated as text Import should never silently replace values with 01/01/1970 ### Operating System Windows 11 + Ubuntu 24.04 ### AppFlowy Version(s) 0.11.1 ### Screenshots ![Image](https://github.com/user-attachments/assets/d41359a1-fcf8-4bf7-a358-f87e474779be) ### Additional Context _No response_

mirror closed this issue

2026-03-23 21:33:41 +00:00

mirror commented

2026-03-23 21:33:42 +00:00

Author

Owner

@twinstef commented on GitHub (Feb 2, 2026):

I compiled the Windows desktop version of AppFlowy from the GitHub repository to try to fix the bug.

Strangely, the compiled version shows version 0.9.9 and not 0.11.1 (even though I cloned the source code yesterday), and the bug doesn't appear in this version.
Dates are imported correctly.

@twinstef commented on GitHub (Feb 2, 2026): I compiled the Windows desktop version of AppFlowy from the GitHub repository to try to fix the bug. Strangely, the compiled version shows version 0.9.9 and not 0.11.1 (even though I cloned the source code yesterday), and the bug doesn't appear in this version. Dates are imported correctly.

mirror commented

2026-03-23 21:33:42 +00:00

Author

Owner

@appflowy commented on GitHub (Feb 4, 2026):

@twinstef Thank you for reporting this. The 0.11.1 use server side csv import. I am working on it. Will let you know when it's ready.

@appflowy commented on GitHub (Feb 4, 2026): @twinstef Thank you for reporting this. The 0.11.1 use server side csv import. I am working on it. Will let you know when it's ready.

mirror commented

2026-03-23 21:33:42 +00:00

Author

Owner

@appflowy commented on GitHub (Feb 5, 2026):

@twinstef Can you try to import the csv again with latest version? It should be fixed

@appflowy commented on GitHub (Feb 5, 2026): @twinstef Can you try to import the csv again with latest version? It should be fixed

mirror commented

2026-03-23 21:33:42 +00:00

Author

Owner

@twinstef commented on GitHub (Feb 5, 2026):

It works, Great Job !
Thanks.

tested with desktop v 0.11.1 win11 AppFlowy Cloud Bêta
notion -> appflowy
apflowy -> appflowy

For information, the import of a period (09/02/2026 → 14/02/2026 ) still doesn't work (but it's an other issue)
tested with notion -> appflowy and apflowy -> appflowy export/import

@twinstef commented on GitHub (Feb 5, 2026): It works, Great Job ! Thanks. tested with desktop v 0.11.1 win11 AppFlowy Cloud Bêta notion -> appflowy apflowy -> appflowy For information, the import of a period (09/02/2026 → 14/02/2026 ) still doesn't work (but it's an other issue) tested with notion -> appflowy and apflowy -> appflowy export/import

mirror commented

2026-03-23 21:33:42 +00:00

Author

Owner

@appflowy commented on GitHub (Feb 22, 2026):

@twinstef Feel free to create another bug report

@appflowy commented on GitHub (Feb 22, 2026): @twinstef Feel free to create another bug report

mirror referenced this issue

2026-03-23 22:20:54 +00:00

[PR #3864] [MERGED] Update translations 🇮🇩 #5918