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

Feature Request: Expose Date() ISO-8601 string #48

Open
shawnsmithdev opened this issue Jan 15, 2019 · 2 comments
Open

Feature Request: Expose Date() ISO-8601 string #48

shawnsmithdev opened this issue Jan 15, 2019 · 2 comments

Comments

@shawnsmithdev
Copy link

The current Year() API is somewhat lacking. An artist may release multiple albums in one year, but with this API one cannot sort those albums chronologically.

I humbly suggest that we expose a new Date() string{...} method that returns ISO-8601 dates, which is to say, depending on available metadata:

  • empty string (no date metadata found)
  • 2018
  • 2018-01
  • 2018-01-15

If this sounds feasible I might try a hand at writing it myself and putting in a PR, but it seems obvious and I wonder if I'm missing a technical reason why Year() was done the way it was.

@shawnsmithdev shawnsmithdev changed the title Expose Date() ISO-8601 string Feature Request: Expose Date() ISO-8601 string Jan 15, 2019
@dhowden
Copy link
Owner

dhowden commented Feb 4, 2019

This is an interesting idea. The varying precision provided by the different metadata types is very frustrating. At one point I considered adding a Date method

Date() time.Time

but then decided against it because too many dates would then have silly values like 2008-01-01 where only the year 2008 is given etc...

Having a string value, that then requires more post-processing by the user is frustrating too, because you then have to introspect the string to work out what it actually means... Maybe we should just add our own date type or something!

@shawnsmithdev
Copy link
Author

Yes if we try parse these, we'd need to store how much precision the value has.

However, my use case is just for sorting, where I actually don't need to process the string at all if the tags actually conform to ISO-8601 (as then it will just sort lexicographical).

I have already done this in my fork and it seems to work, though the test files are only partially updated because id3 and atom are just super weird. I'll probably throw in into a PR soonish.

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

No branches or pull requests

2 participants