start/endDates with only YYYY-MM should be valid

[dbkaplun]

No description provided.

[ocram]

+1 Definitely. Nobody wants to know what day you started your studies at college several years ago.

But it seems to work already, as this tool should be calling the normal CLI as well.

[thisislawatts]

+1 Perhaps also accommodating simply using years.
For example I'm looking to include some of my event based volunteering work. When staffing an annual event it doesn't matter what month it's occurred in and I kind of like keeping my timeline fairly vague, as long as there's an order to things then the rest is of no concern.

As @mwaclawek mentioned, this approach does work when using the online editor, but using the command line returns a JSON error. However the .json is valid, it's actually failed against the schema, maybe the error messages should highlight this?

Cannot export. There are errors in your resume.json schema format.
Try using The JSONLInt Validator at: http://jsonlint.com/

     ✗ work[1].startDate is  expected

[ocram]

@thisislawatts I don't know how this is checked, but according to this document, the "format": "date" that we use for these fields is not even officially supported in JSON Schema.

Anyway, we should probably permit any date in the format YYYY[-MM[-DD]], i.e. YYYY or YYYY-MM or YYYY-MM-DD.

[wdoekes]

There is one drawback, related to #21.

I don't really mind if a date is underspecified, but I would like to be able to cast it do a date so I can order it and/or search through it.

Since the endDate is inclusive, it means that I would have to cast an endDate of e.g. 2013 to 2013-12-31 while a beginDate would become 2013-01-01. That makes using the dates unnecessarily complex.

Isn't it simpler to just choose a choose a date, even though it may not be 100% accurate, and keep the strictness of the date fields? (You want to fill out 2013, but you don't know when exactly it was, you just choose a date like 2013-07-01. Or let your favorite json-resume-editor choose one.)

[thisislawatts]

Hm, that's a fair point, though if you're only going to specify years, then it seems right that you should accept sort order being a little vague. As long as it's capable of grouping your content by year the order is secondary.

• [2013-12-13] Twelve Days to XMas Dance Off
• [2013-05] Summer Camp
• [2013] Christmas Performance

[ocram]

@wdoekes Expanding start years to YYYY-01-01 and end years to YYYY-12-31 doesn't even look that complex to me. Maybe better than forcing the user (or the tools) to just enter some arbitrary (and probably incorrect) month/day.

[DonDebonair]

@wdoekes to me it seems un-user-friendly to require specifying arbitrary precision in dates. I'd rather accept some vagueness in ordering :)

[wdoekes]

Perhaps not. I mainly want to guard against making the json harder to parse programmatically.

But if you feel strongly about this, I won't object.

[lannybroo]

I was also suprised by having to pick a specific date to get the command line tool to validate. A related problem: I don't have an end date for my current job -- is there a way of saying "Present" or something similar?

[osg]

If "present" is used, please keep it lowercase because it is not a proper noun.

[ocram]

Can we come to an agreement here that all dates should support YYYY-MM-DD, YYYY-MM and YYYY?

I don't see any reason not to allow that. It should, of course, be up to the user how specific that information is/must be. And there are valid reasons not to enter the day (or month).

Maybe we can also add the "PR needed" label already, @thomasdavis?

[theox26]

+1 for supporting YYYY-MM-DD, YYYY-MM and YYYY.
+1 for allowing 'present' or allowing a blank end date if that is easier. The theme can then insert 'present' if there is no end date.

[elliottsj]

+1 for YYYY[-MM[-DD]]

For reference, here is the "date" validator currently in use.

One possible solution is to register a custom validator in ZSchema. Perhaps we should create a "resume-date" format?

[szahn]

Agreed. The date should allow for custom formatting so that YYYY and YYYY-MM are valid entries.

[thomasdavis]

My power is out at home at the moment but this first on my to-do list.

[d0minicw0ng]

@thomasdavis Is it possible to also support the August 2014 format? I doubt employers enjoy looking at 2014-08.

[mchelen]

@dominicwong617 The theme can display the date in any format, such as "August 2014", "Aug. '14", etc. This issue is about how the date data is stored.

[d0minicw0ng]

@mchelen When I used the "August 2014" date format, it failed to export (same problem as @thisislawatts) because

Cannot export. There are errors in your resume.json schema format.
Try using The JSONLInt Validator at: http://jsonlint.com/

     ✗ work[0].startDate is expected
     ✗ work[0].endDate is expected

It looks like there is regexp validator for date? I believe you use z-schema for validations and this is where it actually does the validation?

While it works fine on the web editor, I cannot actually have an actual working resume in PDF format. Am I missing something? Thank you!

[mchelen]

@dominicwong617 The JSON should not use "August 2014", it should use "2014-08-01". Then the theme will convert "2014-08-01" into a different format for display.

[d0minicw0ng]

@mchelen Got it, so I just have to find a theme that does the conversion. Thank you!

[mchelen]

@dominicwong617 Yup that's right, glad to help!

[DonDebonair]

We need a PR for this, right? To use a different date type? @thomasdavis are we ok on this?

edit: I just saw #150. In my opinion, we should definitely consider merging that!

[stp-ip]

As we are using ISO8601 for v1.0.0, unspecific dates such as 2015, 2015-01 should be valid too.

[evanplaice]

Fixed in v.0.1.1