Set default date format to keep MM/DD/YYYY instead of MM/DD/YY? (.csv file consideration)

[mikekaganski]

@Villeroy

It is detectable if the user sets the correct locale

@mikekaganski

And if that required user intervention, it is even more important - to keep this user knowledge

I don’t see what does it change.

@Villeroy

I would prefer a vanilla csv

@Villeroy

in order to preserve data consistency

Now what kind of a user expectation it is? Do you even think this can be considered a “user expectation”?

Try to imagine, how many of the hundreds of millions who encounter CSVs, when approached and asked “what do you expect when you open, edit and save a CSV”, would give such a reply? I think, one - you. Everyone else would be like “I expect that the result would be accepted where I send it, and the data gets correct from it, and my main goal of providing them the necessary information is fulfilled”. People expect fitness for a purpose, for a given workflow, and that always includes some third parties that define some “subformat” of CSV, which is implicitly defined by the initial content of the CSV received by the user. Making the program to handle that correctly, is millions of times more important than generating some abstract “vanilla csv” (it one even imagines there’s such a thing - the CSV RFC is not a kind if standard, it has informational status - compare e.g. to RFC 1738, with is “Standards Track”).

[Villeroy]

As long as there is no standard, anything goes as long as it self-consistent.

[sokol92]

Hello! Maybe it’s time to introduce a new Calc option: “When interpreting text as a date, use 4-digit year values in numeric format”?
It can be used for interactive data entry into cells, csv import and in other cases.

[Villeroy]

Whenever you try to build something “fool proof”, nature will come up with better fools. Editing database data in sheets gives birth to all kinds of errors.

I just opened a dBase file with Calc, replaced a date and a decimal with some text, stored and reloaded the file. The date turned into a NULL value (blank cell) and the decimal turned into zero. This is a reasonable way how to handle user errors while keeping the table intact (usable for a database application).

Nothing prevents anybody to enter anything invalid into a sheet cell. The user input may even break the alleged csv schema (import with no text delimiters, then export with column delimiters in strings). Bullshit in, bullshit out.

A uniform csv schema with reasonable formats for numbers, dates, times, decimals and quoted strings could be a benefit for users who don’t know what they are doing when loading csv.

[Stewart]

In reply to sokol92, that sounds pretty much exactly what I want. Obviously didn’t explain myself very well.

[koyotak]

Back to the top!
In the deepness of the programm files i have found something we try to find such more as:

• standard font styles herein: applications > LibreOffice 7-2-7-2.app > contents > resources > calc > styles.xml
• LDML calendars herein: … > resources > liblangtag > common > bcp47 > calendar.xml
• colours: … > resources > palette > libreoffice.soc.

Even afterwards I cannot find listed date formats to change the pre-adjusted sequence.

---

LibreOffice v.7.2.7.2
MacOS 10.11.6

[Villeroy]

CSVed

Csv has always been a database exchange format. Don’t use any spreadsheet program unless you are familiar with all the pitfalls. Of all the problems, date a format with 2-digit years it the smallest one. At least, this format indicates that you imported correct numeric values.