-
Notifications
You must be signed in to change notification settings - Fork 10.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Opting out of date auto-inferring? #3885
Comments
If you just query the field without adding arguments for transformations, it'll return the original string. Is that not what's happening? Date fields are just fancy string fields with extra transformation options. |
That's not what I'm getting out. With |
Oh that's https://www.npmjs.com/package/gray-matter that does that. If you surround the date in a string, it'll retain the original formatting. I filed an issue (jonschlinkert/gray-matter#62) about disabling date parsing. |
Why should surrounding it in quotes do anything? Bare things which aren't bools or ints etc in YAML are strings anyway, are they not? |
gray-matter converts non-quoted bare dates to date objects. |
I dislike magic. When I'm told frontmatter is YAML, that's what I expect. |
@tremby turns out parsing dates is in the YAML spec 🤷♂️ jonschlinkert/gray-matter#62 (comment) |
Seems what most people suggest is if you want to ensure a string in YAML is interpreted as a string than surround it in quotes as YAML supports several other data types that your bare data will be parsed into nodeca/js-yaml#161 |
Well what an idiot I feel. YAML does a lot more than I thought it did. Thanks for looking into it for me, and sorry for the noise. The part of the YAML spec about these timestamps: http://yaml.org/type/timestamp.html It turns out that another way to ensure it's treated as a string is to hint which "tag" should be used. The following all cause it to stay a string:
One thing I'll suggest (and therefore leave this open for now) is that the docs are a bit clearer that this auto-inferring of types from frontmatter via GraphQL isn't Gatsby magic -- it's just what YAML does anyway. Or is that not strictly true in all cases? |
It's js-yaml -> gray-matter -> gatsby — we don't touch the data after we get it from gray-matter. |
Would you like to document this better in gatsby-transformer-remark's README? |
Honestly it might suffice just to replace ". TODO link to docs on auto-inferring types/fields" with "via gray-matter [link]". I think it was this "TODO" tag which put me under the impression that Gatsby was doing a bunch of processing I'd have to fight in the edge cases! |
🤦♂️ oh my — I wrote that like a year ago or whatever. Yes, your update is definitely needed :-) |
Due to the high volume of issues, we're closing out older ones without recent activity. Please open a new issue if you need help! |
I just opened a PR which changes the TODO as I suggested. |
I'm loading data from Markdown files and in my frontmatter I have some date fields.
I've got some dates with no known day; just YYYY-MM (which is a perfectly valid ISO date form). Others are just a year. Others are a full date. All are timezoneless. But no JS date-handling library I'm aware of actually knows how to properly handle incomplete dates. They all treat them like the first of the month or first of the year.
I want to handle these dates in my template, with different behaviour depending on the resolution of the date. So I want to get them as is.
But when I load the data via GraphQL the ones which look like full dates are being converted into datetime strings in the UTC timezone. The others are being left alone. This makes it difficult for me to treat them separately. I can test by regex to see if it's just a year, or a year and a month, and handle those properly. But if it's a full datetime string I need to cut off the time and time zone part (otherwise when parsing it and then formatting it again it might change date due to my time zone offset), and this is a mess I'd really rather avoid.
I just want to opt out of auto-inferring dates. Can I do that?
Better yet, I want to manually specify the transformation to make when these particular fields are requested.
The text was updated successfully, but these errors were encountered: