Skip to content
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

extend date formats for permalinks (especially %j) #926

Closed
danieldriver opened this issue Apr 5, 2013 · 16 comments
Closed

extend date formats for permalinks (especially %j) #926

danieldriver opened this issue Apr 5, 2013 · 16 comments

Comments

@danieldriver
Copy link

Liquid provides date formatting with many of the options available in unix dates. For instance, %j yields the day of the year (001..366).

For a serialized publication that uses the day of the year in a DOI (digital object identifier), it would be a boon to be able to build that number in to the permalink structure. For instance, the url for 2013-04-05-title.md could then be /2013/095/title.html.

I'm sorry that I don't know how easily this might be done. Is there a way to extend liquid date filters to the permalink structure? Alternately, can the date variable %j be made available in _config.yml? Either would seem preferable to manually setting the url in each post's front matter.

@parkr
Copy link
Member

parkr commented Apr 5, 2013

Are you referring to the permalink structure for pages and posts?

@danieldriver
Copy link
Author

Yes. The permalink might be something like /2013/095/title.html rather than /2013/04/05/title.html.

@parkr
Copy link
Member

parkr commented Apr 5, 2013

It's fairly simple! In fact, #890 adds abbreviated month as an option and does a great job of it.

What options would you like to see in addition to %j?

@danieldriver
Copy link
Author

Thanks! I did wonder if #890 was related.

Day of year is most useful for my purposes, and not all of the liquid formatting options seem useful for permalinks. I tend to think zero-padded numbers would be most valuable. In addition to %m and %d (already provided, of course) I might consider:

  • %j - Day of the year (001..366)
  • %U - Week of the current year starting with Sunday (00..53)
  • %W - Week of the current year starting with Monday (00..53)
  • %w - Day of the week (Sunday is 0, 0..6)
  • %H - Hour of the day, 24-hour clock (00..23)
  • %M - Minute of the hour (00..59)
  • %S - Second of the minute (00..60)

If I had to pick one it would be %j. Might even call it year_day or something.

Very excited about the movement on 1.0, btw.

@danieldriver
Copy link
Author

Is the best course of action to duplicate the process followed in #890 and submit a pull request?

@zachgersh
Copy link

Yeah, that would probably be the best way forward. I could also add it for you since I threw in #890 and already have the code open in my editor?

Either way, allowing more customization of the permalinks seems like a fine idea 👍

@danieldriver
Copy link
Author

It would be lovely of @zachgersh to add it on the heels of #890.

@zachgersh
Copy link

Great, I will put a pull request and the required tests in tonight for this! @danieldriver would you mind giving me your preferred short name for each of the items mentioned (just like you did with year_day).

@parkr Is this worthy of the 1.0 milestone tag :)

@danieldriver
Copy link
Author

Suggestions for short names:

  • year_day - %j - Day of the year (001..366)
  • year_week_sun - %U - Week of the current year starting with Sunday (00..53)
  • year_week_mon - %W - Week of the current year starting with Monday (00..53)
  • week_day - %w - Day of the week (Sunday is 0, 0..6)
  • hour - %H - Hour of the day, 24-hour clock (00..23)
  • minute - %M - Minute of the hour (00..59)
  • second - %S - Second of the minute (00..60)

@parkr
Copy link
Member

parkr commented Apr 5, 2013

What is the use-case for each of these options? You mentioned DOI as %j, but I'd love to see some justification for the other ones by way of a use case for each :)

@danieldriver
Copy link
Author

I remember some discussions on the Literature & Latte forums about file naming conventions. Forum moderator AmberV uses some unusual ones for filing and locating text files, and I think it was actually the beginning of my own use of the year_day tag ( %j) in file names.

Under the DOI use case, depending on how many items one put out a day, it might be useful to add hours or minutes. Beyond that I cannot envision a point to having weeks of the year or days of the week.

If I could add just one for use with DOIs, it would be:

  • year_day - %j - Day of the year (001..366)

If I could add two more, they would be:

  • hour - %H - Hour of the day, 24-hour clock (00..23)
  • minute - %M - Minute of the hour (00..59)

These, though, would have to be drawn from something other than the file name. I cannot see myself ever using the others, but I guess you never know how they might be used.

@danieldriver
Copy link
Author

Having said that, I could imagine somebody running a weekly magazine, along the lines of Newsweek or the Economist. In that case, it would be incredibly useful to be able to file posts by week. One might then use either of these:

  • year_week_sun - %U - Week of the current year starting with Sunday (00..53)
  • year_week_mon - %W - Week of the current year starting with Monday (00..53)

@danieldriver
Copy link
Author

It is a bit harder, but not impossible, to imagine somebody wanting to group posts by the day of the week. I'd think there'd be more uses for access to a full Julian date, or even unix time.

FWIW, the date stamp I use in DOI is also called the ordinal date.

@zachgersh
Copy link

I can go with the three requested in the use case (those will come in the pull request). We can consider adding the rest on this thread. I am indifferent but I do believe they will probably be drastically underused.

@parkr
Copy link
Member

parkr commented Apr 6, 2013

Yeah, let's start small. @mojombo, please chime in when you can make the time.

@danieldriver
Copy link
Author

The year_day variable does not pass the rake test. I'm going to submit an alternate in a separate issue with a pull request. (Thanks for showing the way, @zachgersh.)

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants