Better Date Field

This is a suggestion for a minor change of the date field, that is especially important for people from non-Anglo backgrounds: now, the field is open for all kinds of inputs, but as far as I understand, it parses something like 2008-12-14 as 14th of december 2008. However, nothing in the field tells me that this is done this way. Only AFTER having made the correct input the field shows y-m-t to suggest that zotero understood my input. Also, if I only type 2008-12, zotero does not display y-m. However, for non-Anglo's this way of input is non standard and confusing.
I would suggest as an easy way to solve this problem to separate the date field into three different fields, each tagged with year, month and day, respectively. This would make input much easier and intuitive.
«13
  • something like that sounds like a good idea. I'm confused by the date field, too, never know how to input stuff.
  • I would like to update this wish, since it seems to be a fairly easy enhancement that would make life a lot easier and the developers did not seem to take notice.
    best
    Michael
  • I would like to update this wish, since it seems to be a fairly easy enhancement that would make life a lot easier
    How exactly would it make life a lot easier? Currently, you can enter dates almost any way you want and Zotero will parse them fine.
    Also, if I only type 2008-12, zotero does not display y-m.
    The lack of the y-m indicator is a bug. But the field is still being parsed correctly—if you hover over the field, you'll see "2008-12-00", and it will also sort by the date if you add the Date or Year column to the middle pane.
    However, for non-Anglo's this way of input is non standard and confusing.
    Then type it in whatever way makes sense to you. If the parsed date is incorrect, report it as a bug.
    I would suggest as an easy way to solve this problem to separate the date field into three different fields, each tagged with year, month and day, respectively. This would make input much easier and intuitive.
    Three fields doesn't sound easier than one field to me, but dates are also often more complicated than that. The single-field approach allows for dates such as "Summer 2008" to still be sorted as 2008 but passed to bibliographies as a full string.
  • Also, if I only type 2008-12, zotero does not display y-m.
    This is now fixed in the latest dev build. Thanks.
  • thanks for fixing the problem. But zotero cannot parse it correctly, if I, as a non anglo enter as a date for a journal article for july 4th, 1972," 4-7-1972" zotero writes next to the field "y-m-d", which is maybe a bug. But then the output in Chicago is: "April 7", because it understands in anglo-way the first number to be the month and not the day.
    In fact, it cannot parse correctly, because unless the number of the day is higher than 12, how should it find out which number is date and which is month?
    Maybe my original post was unclear, but the main problem is that in continental Europe dates are given usually as day-month-year, or year-day-month and not month-day-year or year-month-day. Thus the zotero interface is counter-intuitive to use and there is nothing that tells me how to use it.
  • if I, as a non anglo enter as a date for a journal article for july 4th, 1972," 4-7-1972" zotero writes next to the field "y-m-d", which is maybe a bug
    The y-m-d just indicates the values that it parses, not the order. We could adjust that, but it's working as intended.
    In fact, it cannot parse correctly, because unless the number of the day is higher than 12, how should it find out which number is date and which is month?
    Zotero determines ambiguous dates based on the user's Firefox locale. If you use a non-U.S. version of Firefox or change your user interface language, it will parse 4-7-1972 as July 4th.

    You can also write "July 4, 1972", "Juli 4, 1972", "4 Juli 1972", etc., regardless of your locale, since it looks for the short forms of English months. If you were using, say, an Italian locale, you could also write "4 luglio 1972", since it also looks for the short forms of months in the current locale.

    The reason you're having trouble now is that you're using a U.S. English build of Firefox with unmodified locale settings and are trying to enter ambiguous dates in a European format.
  • ah, very clever. thanks for this clarification. That makes sense, but from a user point of view, it is simply not intuitive. It would not be too complicated to make three different fields. This would still not prevent from entering something like "summer" in the month field and sorting "2008 summer" correctly. having three fields does not imply that one can only enter numerals and not text.
  • "Summer 2008" was only one example. There are many possible date values, including things like date ranges that wouldn't work well in a three-field system. And there's no need to make dates less readable and more tedious to enter by splitting them up. Computers are smart—they should handle this stuff. (This is why, for example, Google Calendar allows you to type "Dinner with Michael 7pm tomorrow" in a single field.)

    Just typing a date in whatever format you want seems fairly intuitive to me. Problems should be pretty rare, as they'd mostly only occur if people were using a U.S. Firefox build with unmodified locale settings and manually entering an ambiguous date in a purely numerical format. If the y-m-d indicator showed the parse order, it'd be obvious if the order was something other than what was expected. There might be other ways to improve clarity as well, but switching to an awkward multi-field system doesn't seem like a very good one.
  • Hi Dan,
    I totally agree with you (and yes the y-m-d indicator showing how it's been parsed would be wonderful and very intuitive)

    How are date ranges handled?

    See this forum request for a use case.
  • How are date ranges handled?
    At the moment they're not. There's a ticket that would allow date strings that weren't parsed cleanly to be passed through as-is to the CSL engine, and I think Frank's new CSL processor will support that. I'm not sure if there's explicit date range support in the new processor—if so, Zotero would presumably need to parse it and pass the values through, which wouldn't be very difficult.

    I don't know that we need to bother doing anything else with date ranges elsewhere in Zotero. There might be some things we could do regarding sorting or searching or the timeline, but those wouldn't be big priorities.
  • I'll need to back up and be sure that the passthrough mechanism is set up in the processor, but the rough solution that arose from an earlier exchange was exactly as Dan describes: for the processor to receive parsed date fields from Zotero, or a "literal" field if the parse fails.

    I don't think we settled what happens for strings that parse with some cruft left over. For that case, I would like to float two suggestions: (1) that Zotero pass through the parsed date to the processor, and drop the cruft on the floor; and (2) that a date field enclosed fully in quotes be passed through as a literal, regardless of the content, with the quotes stripped.

    There's nothing in there to support ranges -- nor will the CSL language provide support for that at version 1.0. If we did ever stretch to support ranged dates, it would be a complicated business, because you'd need to provide collapsing mechanisms for the various possible date forms (i.e. "Apr. - Jun. 2001" vs "2001-04 to 2001-06"). For the time being, passing through literal strings is simpler, and a "quoted escape" solution will at least provide a means of clearing most of the speed bumps without a lot of manual editing.
  • (1) that Zotero pass through the parsed date to the processor, and drop the cruft on the floor; and (2) that a date field enclosed fully in quotes be passed through as a literal, regardless of the content, with the quotes stripped.
    (1) is the current behavior. As for (2), why bother with quotes? Zotero knows what it supports—and will be made to support as much as the processor supports—and can also discard obvious cruft (e.g., periods after shortened months), so why not just pass through the full string as a literal if it's not a clean parse? The field is designed to be flexible, and I'd like to avoid requiring users to manually mark up the data, since it's more work for them and more work for us everywhere we need to handle that data.
  • @Dan: Got it. That sounds very sensible. I'll get some simple tests of literal passthrough into the test suite.
  • Is it possible that the fixes mentioned here could also be helpful to the issue of original dates (which can not be output in brackets or parens under the current version of zotero)? That is, once developers are tinkering with how dates are entered, perhaps both sets of issues could be resolved?
  • edited September 15, 2009
    Like migugg Aug 3rd 2009 (above), I also found the "y m d" to be very confusing when it appeared next to dates I entered as "August 20, 2009" or "8-20-2009". I thought the "y m d" appearing meant it was interpreting the last "word" in the date ("2009") as the day. Searching the web, I eventually found this discussion, which cleared things up. That's much too hard. Instead of "y m d", It would be better to show the date in some unmistakable format (like "20Aug2009") or even just put some indicator of successful parsing ("OK!" or "Bad!"?). Better yet would be some help function, maybe saying the user can hover over the field to see the stored value.

    I do like having a single date field - it speeds data entry. The hover-over display of the parsed date is good, too, although I did not discover that until reading this discussion.
  • edited September 16, 2009
    I couldn't find/parse for information about a date range on a Conference paper: a conference took place during the period e.g. from Sep 29 to Oct 2, 2008.. What is the correct form to write this down? I tried more structures (2000 Sep 29 - Oct 2), the hoover (so the timeline) almost always gives 2008-10-29 to me, which is wrong. Cheers, M

    p.s. I have found this is not supported yet. I'm looking forward.
  • JonEP's suggestion actually might be a reasonable workaround for the original date issue, which is quite urgent for several of us. That is, pass a string if the date cannot be fully parsed, which would give us 1983[1856] as a workaround for original dates.
  • The pass-through behavior will happen with the new processor in 2.1.
  • Not read this discussion carefully, but will just note that from the CSL perspective, this issues has not been resolved (e.g. I'm pretty resistant to the notion of pass-through literal dates).
  • Literal pass-through isn't intended to be a solution for original dates, but it's necessary for other things (e.g., Hebrew dates) that CSL may or may not ever support.
  • Could the date fields please be made to intepret "today" and/or "now", or even better, ofer a right-click option for this?
  • Sure. Ticket created. Can you give an example of some cases where you would use that, though?
  • Sure - I want to use it as a quicker way to input or update the date in the "Accessed" field, for example when I manually create an item for an online resource such as a blog post, or when I download and manually attach an updated copy of someone's manuscript from their web page.
  • I see the use of this, but wouldn't it be handier to implement a right-click menu for date fields similar to the "Transform Text"-menu for the title field? It could just contain a single option, e.g. "Use current date/timestamp".
  • I prefer Rintze's option - seems both cleaner and more intuitive.
  • @Dan:
    Literal pass-through isn't intended to be a solution for original dates, but it's necessary for other things (e.g., Hebrew dates) that CSL may or may not ever support.
    But the spec does not support such a notion (though in my thinking, I've always considered an "other" date component than is effectively a literal), and we really ought to have some consensus about how this will work; both in CSL, and data import/export. If not, different applications will simply yield different results (which is not necessarily the end of the world).
  • edited November 7, 2009
    What is the scope of issues to be settled?

    Citeproc-js currently accepts date information broken down into year, month, day, season, and a circa bit. To handle cases in which the calling application cannot provide those details, it will recognize a "literal" entry in lieu of a structured date. Passthrough is not an ideal solution to unparsed dates, but the alternatives (silently leaving the date empty, placing an error slug on the output, or passing a corrupted and possibly misleading date) are worse. Literal strings are rendered without special formatting. I don't see what else one could do with them, since nothing is known about their content.

    I'll be happy to change the processor interface if it will help in some way; I put the interface description online in the hope of receiving feedback on things that should be altered. But so long as everyone is in agreement that some form of literal passthrough is to be recognized (which does seem to be necessary), a standardized interface that includes that possibility, when it is settled, could also be left for implementation in an intermediate layer, independent of the processor.

    (PS: Just to amend what I wrote earlier, we do have ranged date support in citeproc-js now.)
  • To handle cases in which the calling application cannot provide those details, it will recognize a "literal" entry in lieu of a structured date.
    So is "Summer 2000" a literal, or is "2000" the structured year and "Summer" the literal? What's Zotero's plan for data import/export of these dates vis-a-vis the RDF?
  • Frank's processor supports a 'season' element, so "Summer 2000" will be fully structured (and localized).

    RDF import/export isn't my department, so I can't comment on that.
Sign In or Register to comment.