This user's frustration is entirely justified, and the problem they describe is a textbook example of software prioritizing display logic over data integrity. When a tool like Excel or a CSV exporter looks at a 14-digit ID and decides it *looks* like a number, then converts it to scientific notation, it isn't helping. It is destroying information. The fact that the user went into Options, unchecked every box related to scientific notation, and still got the same behavior tells us the issue isn't user error. It is a baked-in assumption by the software that it knows better than the person using it.
The practical cost here is obvious and painful. That screenshot showing multiple run_id values all appearing as "3.73E+14" is a data disaster. Those IDs are different. They are supposed to be unique identifiers, the backbone of any relational database or audit trail. Once Excel rounds them and displays them in scientific notation, the user can no longer distinguish between records, join them back to the source database, or trust that a single export is accurate. The workaround, formatting cells as text before pasting, is well known, but it is a brittle, manual step that fails the moment someone forgets to apply it. For a user managing thousands of records, this isn't an inconvenience. It is a productivity blocker that erodes trust in the export process itself.
What this reveals is a deeper tension between legacy spreadsheet behavior and modern data workflows. Traditional spreadsheets were built for human-readable numbers, not machine-readable identifiers. They assume a number is a quantity to be calculated, not a token to be preserved. That assumption is outdated. In a data environment where every row has a UUID, a hash, or a long integer primary key, the software's first job is to leave that data alone. The user should not have to fight the tool to keep their own data intact.
Our opinion is plain: this behavior is a design failure that needs a permanent, user-accessible fix, not another checkbox that doesn't work. A proper solution would treat any field detected as a long numeric identifier as a text string during export, preserving its full value without requiring user intervention. Until that happens, the burden remains on the user to police every export. That is not empowering. It is a roadblock that makes a simple task, exporting your own data, feel like a negotiation with an uncooperative tool.