Presumably foreign month names can be parsed by using localized CSL terms lists--not sure about seasons.
CSL 1.0 locales contains terms for months and seasons.
Have you figured out how to deal with months/seasons? It would be great to sort June 2001 or Summer 2001 before September 2001 or Fall 2001, i.e. to parse the seasons as well. But if you display the parsed date (2001-09-01) first and have users roll over every time to make sure it's a month/season and not an exact date, it would be extremely confusing an inconvenient to the user.
I'm concerned about how the parsing works inside Zotero-- if I enter "10 декабря 2009 г." in a date field, Zotero parses it as 2009-00-10. I hope that it does parse correctly for users in the "ru" locale, but there's no reason to expect that my data will all be in the locale that I prefer to use Firefox in.
If this works correctly in citeproc-js, that's great, but it still needs to work fine on the Zotero client side as well.
If it is not feasible to try parsing in every possible locale, perhaps I could click and set the date locale manually (a la Frank's solution for the multilingual project)?
Have you figured out how to deal with months/seasons?
The convention in some library spec whose name I'm forgetting is to treat them as month numbers; IIRC 41-44. Something like that is probably the best approach. Might be worth checking with the initial suggestions out of the EDTF group though.
... season sorting is tricky as items might originate from either the northern or the southern hemisphere
Yeah, but practically speaking, the use case for this is a narrow one: certain periodicals. And we can simply say that the "date" in that case is the cover date, in which case all that matters is the season listed on the cover.
I guess it does matter somewhat on output, as if you assume the order based position in the year, someone in the Southern hemisphere might expect Fall to go first, Summer last. I still think the sorting of the seasons themselves is less critical than getting them right in relation to months though.
I'm concerned about how the parsing works inside Zotero-- if I enter "10 декабря 2009 г." in a date field, Zotero parses it as 2009-00-10. I hope that it does parse correctly for users in the "ru" locale, but there's no reason to expect that my data will all be in the locale that I prefer to use Firefox in.
I believe Zotero—due to the way locales are loaded—currently parses in the current locale and in English, but obviously that's not ideal. (And actually, it uses a combination of interface locale and bibliography locale, because day suffixes are/were only available in the interface locale. It also parses using only the month name abbreviations, which might not work as well for languages other than English?)
I believe Zotero—due to the way locales are loaded—currently parses in the current locale and in English, but obviously that's not ideal. (And actually, it uses a combination of interface locale and bibliography locale, because day suffixes are/were only available in the interface locale. It also parses using only the month name abbreviations, which might not work as well for languages other than English?)
@Dan: I reported a closely related problem here. Could it be fixed in the next Zotero release? Thanks.
I was reminded of this unfortunate thread and I'll give it one more try, by citing my own proposal, which though probably not perfect from the nerd's point of view is at least way more coherent than the current confusing state of the date field:
Proposal Considering that (1) the great majority of items enters the library through translators, and (2) the great majority of items has completely parseable dates, make sure that parseable dates (which would be the great majority of all dates in almost any database) are all displayed in the same format by default. The proposal is concerned simply with maximizing consistency while respecting exceptions. I don't see what good it does to perpetuate informationally equivalent idiosyncrasies, at least not in basic user-facing UI elements, but if it is considered useful to keep the date as it was originally entered, make it available as a tooltip - but don't shown the idiosyncrasies by default for fully parseable dates.
I'll leave it to the locale angels what date format should be the default (possibly a localized format, though yyyy-mm-dd would be a fine start), and I'll leave it to the data parsing angels to handle dates that are not or not fully parseable. That said, I will note again that I don't see why a major improvement like this should wait for minor points that don't affect the essentials of the proposal. As they say, release early, release often.
Rationale See my detailed posts above and consider the many threads on the forum which show that the field is confusing the hell out of people. Also consider that nobody wants to proliferate the perfectly parseable idiosyncratic differences between repositories (e.g. Feb 08 vs 02/2008, etc.).
Mark: There's nothing unfortunate about this thread, though. It exists, and it will be referred to by whoever ends up working on this (which, for what it's worth, could be someone other than the core devs).
As a temporary, partial improvement, the date parsing indicator in the next major release will show the actual order of the component parts. (Other improvements could still make it in, but that one's in already.)
Myself and a dozen odd people in my lab are eagerly awaiting this feature to be fully implemented. We all use Zotero for citations and tire of manually changing dates to get a consistent format.
What steps are required to make the date field display a consistent YYYY-MM-DD format? I have written a few translators for Zotero, but have never mucked with the core. However, I am a professional C++ and Python graphics programmer and have experience with web programming (JS, HTML, CSS, PHP, etc.), so it (probably) wouldn't be a huge stretch to try my hand at it. Where should I start, besides reading the dev documentation?
just to make sure we're on the same page - what do you need the unified date display for?
I understand the UX aspects of what mark has been pushing for, but I want to make sure that it's clear that on the functionality side there's little difference. Zotero already does date sorting correctly (i.e. chronologically) in the middle panel and citation styles use the parsed date.
So while I do understand why it'd be better to have dates displayed uniformly, I'm not sure I understand why you'd ever want to manually change dates - what's the use case that makes uniformity that important? (I'm not saying there isn't one, I just want to be clear what it is).
As for where to look: Here's Dan's commit for the YMD fix: https://github.com/zotero/zotero/commit/bc12d9263991f064a3bc35e5ed898554dbed1127 the date.js and itembox.xml files would probably be the main ones to modify, although given the various issues raised above this may also require other changes, including potentially adding a preference.
Search for 'accessDate' in itembox.xml to see an example of a field that shows something different between when it's displayed and when it's edited. I wouldn't want to pref this. Without rereading the above, I'd think it'd have to be something like showing in a standard format only if it parsed completely with nothing left in 'part' from strToDate().
@adamsmith
My issue is UX, just like Mark's.
As for why I manually change dates, it is mostly because my database is very large (over 5,000 articles) and having to cross my eyes to compare dates in different formats when scanning a dozen articles is maddening, especially since I have to do it ten or more times a day frequently. These little paper cuts add up over time - and I have been using Zotero since 2007!
@Dan and @adamsmith
Thanks for the direction. I will take a look this weekend (while I am snowed in). I will keep in mind that this should not be preffed.
Hi all,
Been using - and really appreciating - zotero for several years now. just curious if any progress was made on this issue? Searching the forums, it seems most conversations have gotten sidetracked into discussions about locales. This appeared to be the most promising thread.
I'll echo the comments above that the center pane date column can be very hard to read if I have sorted by something other than date (which I know it sorts correctly). I have dates appearing as
"2013", "October 24, 2013", "October 2013", "2013/10", "2013/10/24", "10/24/2013", and "2013-10-24".
Reading these is manageable, but it does slow me down.
Is there any way for the center pane's date column to display dates in a consistent format?
@BBUCommander, did you have any luck with your attempt?
Yes I did, but I never got around to submitting my work and subsequently forgot. I blame getting involved in a Google Summer of Code. =)
When I get some free time this month I will port my code to the latest dev version of Zotero and make a pull request. Apologies for the ridiculously long delay.
I haven't looked into it extensively, but I think it would be relatively straightforward to batch-reformat the date field using the javascript API and ExecuteJS (in Firefox Zotero).
To add a different perspective to this discussion, I personally hate the YYYY-MM-DD standardized format for reading. Unless it is can be preferenced, I definitely would not want a standardized display of dates to be implemented.
bwiernik: Don't worry, any "standardized" format we would implement would be either locale-specific or customizable. YYYY-MM-DD is a format for computers.
yeah, I'd be against ISO dates, too, but that doesn't mean they can't be standardized, e.g. the same way the date added field is (though that has its own localization issues). edit: so what Dan says.
Pretty sure this isn't going to be in 5.0, which is likely feature frozen or almost so. This wouldn't have to be part of a major version upgrade, so it could make it anywhere in between in an incremental release. My sense is that it's not a top priority, though, so absent someone outside of the core devs taking it it may well take longer.
Currently the displayed format is always the ISO date because this is the format I prefer, but a final solution would probably create a user setting to toggle between ISO or locale dates with locale being the default. Alternatively users could choose a custom date format. I am fine with any solution that allows ISO dates.
Thank you for taking the time to work on this @BBUCommander! Hopefully you can address the concerns raised at the pull request so it can be included as soon as possible.
Upgrade Storage
If this works correctly in citeproc-js, that's great, but it still needs to work fine on the Zotero client side as well.
If it is not feasible to try parsing in every possible locale, perhaps I could click and set the date locale manually (a la Frank's solution for the multilingual project)?
I guess it does matter somewhat on output, as if you assume the order based position in the year, someone in the Southern hemisphere might expect Fall to go first, Summer last. I still think the sorting of the seasons themselves is less critical than getting them right in relation to months though.
PS: Sorry for the slightly off-topic.
Proposal
Considering that (1) the great majority of items enters the library through translators, and (2) the great majority of items has completely parseable dates, make sure that parseable dates (which would be the great majority of all dates in almost any database) are all displayed in the same format by default. The proposal is concerned simply with maximizing consistency while respecting exceptions. I don't see what good it does to perpetuate informationally equivalent idiosyncrasies, at least not in basic user-facing UI elements, but if it is considered useful to keep the date as it was originally entered, make it available as a tooltip - but don't shown the idiosyncrasies by default for fully parseable dates.
I'll leave it to the locale angels what date format should be the default (possibly a localized format, though yyyy-mm-dd would be a fine start), and I'll leave it to the data parsing angels to handle dates that are not or not fully parseable. That said, I will note again that I don't see why a major improvement like this should wait for minor points that don't affect the essentials of the proposal. As they say, release early, release often.
Rationale
See my detailed posts above and consider the many threads on the forum which show that the field is confusing the hell out of people. Also consider that nobody wants to proliferate the perfectly parseable idiosyncratic differences between repositories (e.g. Feb 08 vs 02/2008, etc.).
What steps are required to make the date field display a consistent YYYY-MM-DD format? I have written a few translators for Zotero, but have never mucked with the core. However, I am a professional C++ and Python graphics programmer and have experience with web programming (JS, HTML, CSS, PHP, etc.), so it (probably) wouldn't be a huge stretch to try my hand at it. Where should I start, besides reading the dev documentation?
I understand the UX aspects of what mark has been pushing for, but I want to make sure that it's clear that on the functionality side there's little difference. Zotero already does date sorting correctly (i.e. chronologically) in the middle panel and citation styles use the parsed date.
So while I do understand why it'd be better to have dates displayed uniformly, I'm not sure I understand why you'd ever want to manually change dates - what's the use case that makes uniformity that important? (I'm not saying there isn't one, I just want to be clear what it is).
As for where to look: Here's Dan's commit for the YMD fix: https://github.com/zotero/zotero/commit/bc12d9263991f064a3bc35e5ed898554dbed1127 the date.js and itembox.xml files would probably be the main ones to modify, although given the various issues raised above this may also require other changes, including potentially adding a preference.
My issue is UX, just like Mark's.
As for why I manually change dates, it is mostly because my database is very large (over 5,000 articles) and having to cross my eyes to compare dates in different formats when scanning a dozen articles is maddening, especially since I have to do it ten or more times a day frequently. These little paper cuts add up over time - and I have been using Zotero since 2007!
@Dan and @adamsmith
Thanks for the direction. I will take a look this weekend (while I am snowed in). I will keep in mind that this should not be preffed.
Been using - and really appreciating - zotero for several years now. just curious if any progress was made on this issue? Searching the forums, it seems most conversations have gotten sidetracked into discussions about locales. This appeared to be the most promising thread.
I'll echo the comments above that the center pane date column can be very hard to read if I have sorted by something other than date (which I know it sorts correctly). I have dates appearing as
"2013", "October 24, 2013", "October 2013", "2013/10", "2013/10/24", "10/24/2013", and "2013-10-24".
Reading these is manageable, but it does slow me down.
Is there any way for the center pane's date column to display dates in a consistent format?
@BBUCommander, did you have any luck with your attempt?
Thanks!
When I get some free time this month I will port my code to the latest dev version of Zotero and make a pull request. Apologies for the ridiculously long delay.
Also, failing that, has anyone had any luck at standardizing disparate date fields in a one-off way? (eg by munging the database fields)
Thanks for any suggestions!
I haven't looked into it extensively, but I think it would be relatively straightforward to batch-reformat the date field using the javascript API and ExecuteJS (in Firefox Zotero).
edit: so what Dan says.
Couldn't this be added to 5.0? It seems like a reasonably simple issue to tackle, unless I'm missing some unseen complications...
This wouldn't have to be part of a major version upgrade, so it could make it anywhere in between in an incremental release. My sense is that it's not a top priority, though, so absent someone outside of the core devs taking it it may well take longer.
Currently the displayed format is always the ISO date because this is the format I prefer, but a final solution would probably create a user setting to toggle between ISO or locale dates with locale being the default. Alternatively users could choose a custom date format. I am fine with any solution that allows ISO dates.