On 02.11.2011 09:02, Jacob Carlborg wrote:
On 2011-11-01 02:28, Jesse Phillips wrote:
On Mon, 31 Oct 2011 19:21:02 +0200, Vladimir Panteleev wrote:
On Fri, 28 Oct 2011 16:18:27 +0300, dsimcha<dsim...@yahoo.com> wrote:
Docs:
http://nascent.freeshell.org/programming/D/doc/phobos/std_csv.html
Checked the new docs today. If I'm reading them right, the top example
prints:
"Fred works as a Fly and earns $4 per year"
Is this a pop culture reference I'm not catching?
No, not that I know of. Should it be? Should I go with a more
professional like example?
An idea I had the other day was to include convenience presets for the
more common flavours of CSV formats, e.g.: csvText!CSVFormat_Excel(...)
Well if Excel actually conforms to what it claims:
http://office.microsoft.com/en-us/excel-help/excel-formatting-and-
features-that-are-not-transferred-to-other-file-formats-HP010014105.aspx?
CTT=5&origin=HP010099725#BM4
Which I doubt it does, then my parser already defaults to being able to
read such formats. In my experience Excel sucks at CSV and follows no
rules.
The implementation I choose as default is the most common and any other
style is just a butchafication and likely to be unreliable, usually stems
from "my data has commas, so I'll use colon." Which is great until the
data also has colon. But maybe that is just my experience.
Excel + CSV == Pain in the ass
Excel uses different value delimiters as the default setting depending
on the locale of the Excel application.
Far more horrible than that -- in an old Excel from around 2000 the user
interface used US settings for reading short dates, if the day of the
month was 12 or less. Otherwise it uses the locale. But it always uses
the locale for displaying them.
So 11/1, 12/1, 13/1 gets changed to 1 Nov, 1 Dec, 13 Jan.
I wrote a macro called "November 9" (9/11) for swapping them back if
they were in the buggy range.
