-
Notifications
You must be signed in to change notification settings - Fork 18
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
Date/time consistency issues in our peer review data processing workflow #179
Comments
+1 and also it would be good to specify YYYY-MM-DD or YYYY/MM/DD consistently, I blv the current review template is MM/DD/YYYY |
agreed!! We can always parse the review template in it's current form. let's go with
we can strip the time piece as we don't need it! and use that throughout. i think that is jekyll friendly too? |
We can just format it however we want with Jekyll :)
|
ooooh perfect!! i forgot about filters!! 🚀 |
The data in this workflow are used to populate our website via this data file.
Right now our output YAML file has date fields for the following keys:
devicely return
date_accepted: '2021-08-19'
created_at: 2021-04-03 19:25:41+00:00
updated_at: 2023-08-29 02:06:23+00:00
closed_at: 2022-09-07 15:40:27+00:00
pygmt return
date_accepted: 2022-9-1
created_at: 2021-07-23 00:37:07+00:00
updated_at: 2023-09-14 17:47:44+00:00
closed_at: 2023-06-12 22:47:16+00:00
We should make all of our date fields consistent across our models.
NOTE: We also have date fields in the GHMeta object for reach project repo.
related to and can close #130
see pr 404 here for what the diff on the output contributor file looks like.
For our website purposes, it would be ideal if the workflow returned just the date (we don't need time) and ideally it should ouput it as a string for Jekyll processing. If you are reading this and know more about processing dates with jekyll and it doesn't have to be a string, then that is ok too. the goal here is consistency! so let's get the date field consistent via a uniform validator and datetime type for every date related field.
The text was updated successfully, but these errors were encountered: