Standalone date formats - Date accessed format

Thank you for a great product.

I had the date format trouble trying to get non-US date formats. Found the relevant thread and made the changes suggested:

https://forums.zotero.org/discussion/6797/zotero-appearance-how-do-i-change-date-format-in-date-added/

In Zotero Standalone, open about:config (Preferences->Advanced->about:config), set intl.locale.matchOS to false, and set general.useragent.locale to en-GB and see if it makes things look like you want them to. If this is the issue, it's a bug we inherit from Mozilla and it's probably not going to be an easy fix.
_______

All is good now save for one little issue. All date formats seem to be DMY (en-GB) but for the date accessed field that remains in MDY (en-US) format, or at least it does to my eyes.

Full disclosure: Zero knowledge of coding.

I need date formats to be in one and only one format and that format has to be DMY. having different formats in the same Application is asking for errors and I type dates automatically in DMY.

What might I try next? Thanks for any help.
«1
  • All is good now save for one little issue. All date formats seem to be DMY (en-GB) but for the date accessed field that remains in MDY (en-US) format, or at least it does to my eyes.
    Are you referring here to the date format when editing the field?
  • The visible date format after editing the field is MDY. If I click into the field it changes to YMD.
  • Additional information that might help is assisting me:

    The date format in the date accessed field will be the same format as that in the date field if that last one has a complete date. In my case, the date format reflects the changes made in general.useragent.locale (en-GB) so DMY.

    If there is only a year entered, for example when the publication lists only the year of publication, or only a year and month, then the date format for the date accessed field will be MDY.
  • in assisting me. Pardon my spelling.
  • The first thing I'd ask is: Why are you manually adding date accessed information? Or am I misunderstanding something?
    Automatically added dates should appear fully as
    "Mon 17 Feb 2014"

    I can't actually add access dates without a day at all and that makes sense to me.
  • Because I'm importing from Mendeley and adding existing pdf's for which I have access dates.
  • FWIW, Mendeley does export access dates in bibtex, though not in RIS, so it may be worthwhile using the former.

    But do I understand correctly that the format of the access date field depends on the amount of information input in the publication date field? That seems quite odd.
  • I did export Bibtex. But all the access dates were absent when opened in Zotero. I've come to expect that when transferring data between different applications. So I didn't think there was a problem.

    So no I'm reentering all the "dates accessed" manually and using DD.MM.YYYY format which is the usual format here in Switzerland. All that matters is that the day comes before the month so I can scan dates with out having to stop and convert between formats.

    I don't know whether it's odd or not. All IT behaviour is odd to me. But then I know only what I think I need to know which is never enough.
  • edited February 18, 2014
    access dates import fine for me from Mendeley but oh well.

    But could you confirm that I read your description of the issue correctly?
    I.e. " the format of the access date field depends on the amount of information input in the publication date field?"
  • Ok. Double checked. Not consistently. Maybe unrelated.

    But the date accessed fields are showing two different formats.

    Some MDY and others DMY.

    If I add month or day, the format remains the same for those that only have year..

    I looking at date accessed and not date added. Which is showing WEEKDAY MONTH DD HH:MM:SS YYYY
  • edited February 18, 2014
    OK, so look at some examples to see what exactly is happening.
    How exactly are the dates displayed?
    as
    MM/DD/YYYY ?

    how do you know whether they're MDY or DMY?

    Does it matter whether dates you input are unambiguous?
    E.g. 17.2.2013 is DMY and Zotero will always recognize it as such. But 2.2.2013 could be both and I'm not sure what the accessed field would do with that.
  • So. Document A, accessed 11 February 2014.
    I enter 11.02.2014 and Field reverts to 02/11/2014
    If I click in Field highlighted date reads 2014-03-12.
    Second attempt: I enter Feb 11 2014 and field reverts to 02/11/2014 and highlighted date reads again 2014-02-11

    It is important that, when visually scanning entries and data in right-hand column, all dates are in same formats so that I can read them without converting them mentally.
    So, yes it is important that the dates are unambiguous.
  • Hmm - I'm not making myself clear.
    I'm trying to figure out what's going on here. When I ask "Does it matter whether dates you input are unambiguous?" I don't mean "is it important to you" but rather "does it change the outcome".

    Above you say you sometimes get DMY and sometimes MDY.
    Your example are all the different ways in which you get MDY.
    Can you actually get an access date to display at DMY? How?
  • Sorry. Misunderstood. No. It doesn't change the outcome.

    And now I see what you were talking about before. The dates I thought were DMY in the accessed field may n fact MDY. But I have no way of knowing.

    So. Problem in fact is that date filed and accessed field seem to be giving two different formats.
  • The (publication) date field doesn't have a standard format. It always displays the date the way you entered it and displays YMD in the appropriate order.

    To see what your actual date display settings are, add the "Date Added" (and I mean date added, not accessed) column to the middle panel by clicking on the little table icon at the top of the middle panel. Are the dates in that column DMY or MDY?
  • actually, just tried this out - the accessed field in the right-hand panel does indeed not localize and will always display either as MM/DD/YYYY or the full written out date format like the Date Field (the latter is what Zotero itself creates).
    There is no current solution and I don't think there'll be a fix very soon. Adding manually, the safest way to enter dates is YYYY-MM-DD.

    Note that the accessed date in the middle panel (which you can add, too), is displayed in localized form.
  • OK. Excellent. Didn't try the field in the middle panel. Just assumed it would be the same. But that works for me.

    Can't pretend to understand why the accessed field in one panel won't follow the formats other date fields, including the accessed date in another panel, use.

    The ways of our IT overlords and masters are indeed mysterious.

    Thanks for all the help and the time spent on resolving this.
  • edited February 19, 2014
    So, first:

    https://forums.zotero.org/discussion/21431/accessed-field-displays-date-wrong/#Item_18

    As far as I know, Mozilla's date-locale functions have been broken on some systems for years. So anything that's just flat-out wrong (which may or may not be the case above — I'm not sure if samooresa just mistyped regarding "11.02.2014"/"02/11/2014" => "2014-03-12") is likely because of that.
    actually, just tried this out - the accessed field in the right-hand panel does indeed not localize and will always display either as MM/DD/YYYY or the full written out date format like the Date Field (the latter is what Zotero itself creates).
    I'm not sure what you mean here by "full written out date format", but here's what I'm seeing: if I either save a webpage or paste a full SQL datetime into the field ("2014-02-19 03:59:43"), it's interpreted as local time, saved as UTC in the database ("2014-02-19 08:59:43"), displayed in the right pane in localized date/time form ("Wed Feb 19 03:59:43 2014", the output of Date.prototype.toLocaleString()), and displayed in the middle pane in local time ("2/19/14 03:59:43"). All good so far.

    If I put in anything else — "2014-02-19", "Feb 19 2014", "Feb 19 2014 12:34:56", "19/02/2014", "today" — it's parsed as a date string with the time portion ignored, interpreted as 2014-02-19 00:00:00 UTC, stored in the database as "2014-02-19", displayed in the right pane as "02/19/2014" (the output of Date.prototype.toLocaleDateString(), I believe) when viewing and "2014-02-19" when editing, and displayed as 2/18/14 19:00:00 (for EST) in the middle pane. All good except the middle pane. (Theoretically we could parse the time, but we don't have any code for that now.)

    In either case, we're at least trying to display a local date in all places, and if that's not working in the right pane it's probably a Mozilla (or Unix distro) bug. It looks like Firefox 29 is making a lot of improvements to the date locale functions, so hopefully things will get better then. In the meantime, I think that there are both absolute errors on some systems and also cases of relying on various system locales, which may not be what the user wants, rather than the Mozilla locale. We can look into using the same logic as we do in the middle pane — which I think is our own custom date handling — but at least in theory we're doing the right thing already.

    In terms of our own behavior, the main problem seems to be the middle pane. We want to parse time-less dates coming out of the database (e.g., "2014-02-19", which is how any non-SQL-datetime date parsed as Feb. 19 should be stored already) as 00:00:00 in the local timezone for the purposes of the middle pane but leave off the time part when displaying it. So the middle pane in my case would say just "2/19/14". The right pane would continue to say "02/19/2014" (unless we switch it to using the same logic as the middle pane in order to fix upstream bugs).
  • --- I'm not sure if samooresa just mistyped regarding "11.02.2014"/"02/11/2014" => "2014-03-12") is likely because of that.---

    No mistype. Your para below confirms that. 11.02.2014 is the string I enter (it's the way dates are most often entered, displayed and printed in Switzerland for the most part), 02/11/2014 is the date displayed when viewing and 2014-03-12 is the date displayed when editing, exactly as you describe below for the last two.

    ---stored in the database as "2014-02-19", displayed in the right pane as "02/19/2014" (the output of Date.prototype.toLocaleDateString(), I believe) when viewing and "2014-02-19" when editing, and displayed as 2/18/14 19:00:00 (for EST) in the middle pane.---

    As a user, my issue with this: the displayed date format should be consistent across all date fields. And I would like to be able to change the date format to one of my choice at least from a list of standard formats. That's all.

    So please don't change the middle pane. Thank you again for finding a work around to this problem.
  • edited February 19, 2014
    No mistype. Your para below confirms that. 11.02.2014 is the string I enter (it's the way dates are most often entered, displayed and printed in Switzerland for the most part), 02/11/2014 is the date displayed when viewing and 2014-03-12 is the date displayed when editing, exactly as you describe below for the last two.
    That's not at all what I described. You have two different dates there: February 11th and March 12th. That's what I'm suggesting was a typo. If not, then you're seeing something totally different from what I'm talking about, which is just three versions of the same date. In either case, I explained the issues above.
    So please don't change the middle pane.
    Sorry, but you're misunderstanding the problem. The middle pane is showing an incorrect local timestamp relative to the time-less local date entered into the right pane. (It may not look as incorrect to you if you're east of UTC, but if it includes a time it's incorrect for a non-SQL-datetime date.) I can't really explain it beyond what I have above, but I think at this point you'll have to trust that we understand the issues and will resolve them as best as we can.

    Thanks for reporting.
  • No mistype. Your para below confirms that. 11.02.2014 is the string I enter (it's the way dates are most often entered, displayed and printed in Switzerland for the most part), 02/11/2014 is the date displayed when viewing and 2014-03-12 is the date displayed when editing, exactly as you describe below for the last two.

    --That's not at all what I described. You have two different dates there: February 11th and March 12th. That's what I'm suggesting was a typo. If not, then you're seeing something totally different from what I'm talking about, which is just three versions of the same date. In either case, I explained the issues above.---

    Quite, yes. The typo being in the date displayed when editing. Ok. it should have been 2014-02-11 in my posts. Sorry about that. It is three different formats showing for the same date that was my problem. I understand a solution may be coming. Thanks for the answers.

    Not changing the second pane was a quip. A sad attempt at humour. As in "please don't change what's working for me". Only users without an IT background would get the humour I suppose. Or maybe not.

    Again thank you very much for your help and I look forward to the fixes; be they yours, Mozilla's...
  • I'm not sure what you mean here by "full written out date format", but here's what I'm seeing: if I either save a webpage or paste a full SQL datetime into the field ("2014-02-19 03:59:43"), it's interpreted as local time, saved as UTC in the database ("2014-02-19 08:59:43"), displayed in the right pane in localized date/time form ("Wed Feb 19 03:59:43 2014", the output of Date.prototype.toLocaleString()), and displayed in the middle pane in local time ("2/19/14 03:59:43"). All good so far.
    yes, that's what I'm seeing and I agree that's how it should be. "By full written out" I meant localized including weekday as in "Wed 19 Feb 2014 08:07:53"
    If I put in anything else — "2014-02-19", "Feb 19 2014", "Feb 19 2014 12:34:56", "19/02/2014", "today" — it's parsed as a date string with the time portion ignored, interpreted as 2014-02-19 00:00:00 UTC, stored in the database as "2014-02-19", displayed in the right pane as "02/19/2014" (the output of Date.prototype.toLocaleDateString(), I believe) when viewing and "2014-02-19" when editing, and displayed as 2/18/14 19:00:00 (for EST) in the middle pane. All good except the middle pane. (Theoretically we could parse the time, but we don't have any code for that now.)
    I think we're on the same page, but just to make sure: The problem that samooresa has is that the accessed date in the right-hand panel is not localized, i.e. even with an en-GB locale, entering 2014-02-19 gives you 02/19/2014 as the displayed date. The middle panel has the time mix-up you note, but does display a correctly localized version as 19.2.2014 with an en-GB locale (that's the part s/he doesn't want changed). If I understand you correctly, there is a chance that FF 29 will fix the displayed date in the right hand panel, so fingers crossed, but I think you'd agree that having the same date displayed as DD.MM.YYYY in the middle panel and MM/DD/YYYY in the right hand panel isn't right? (I'm wondering though: since Zotero is able to display the localized date in the middle panel, couldn't we use the same function for the right-hand panel?)
  • Er. your second para: precisely.

    Thank you.
  • Re* your second para. Commuting and the ride is rough.
  • The problem that samooresa has is that the accessed date in the right-hand panel is not localized
    It's not being displayed as localized. I'm saying that it is localized in terms of our code. (And again, I suspect this is affected by the underlying OS as well, so it probably works for some people already.)
    If I understand you correctly, there is a chance that FF 29 will fix the displayed date in the right hand panel
    Yes.
    I think you'd agree that having the same date displayed as DD.MM.YYYY in the middle panel and MM/DD/YYYY in the right hand panel isn't right?
    Yes, of course. By "all good except the middle pane" I meant that we are, in fact, localizing the right pane properly, which is why it works for me. The Mozilla date-locale function just isn't working right on some systems.
    (I'm wondering though: since Zotero is able to display the localized date in the middle panel, couldn't we use the same function for the right-hand panel?)
    We can — I suggested this as a possibility above. But I think we want to see what Firefox 29 offers first.

    One other issue that I didn't address is the format when editing. Right now it's YYYY-MM-DD, because it's unambiguous and non-locale-specific, but it's obviously a little ugly. We can't display the Mozilla localized output, though, because we have no control over what that will be, and it may not round-trip through our parsing function. I'm not sure exactly what we're doing in the middle pane now, but if we can be sure that what we use there will always round-trip, we could use that instead.
  • Hello,

    SO I need en-GB type dates, I've checked that about:config knows I am GB (I hope, I am not good at computers), but when I generate a bibliography it uses access dates in American format. For example, something I have added today is shown in the right hand Zotero pane as "Accessed: 02 March 2014", when I click on that it shows "2014-03-02", and in my bibliography it shows up as "(accessed 2.25.14)".

    How can I make my dates come out in British format DD/MM/YYYY, please?

    I am not great at computers, simple instructions much appreciated, thank you.
  • wait - the same date that shows up as March 2nd shows up as 2.25 in the bibliography?
    That'd be very odd. Otherwise, the date format depends on the citation style. Which are you using?
  • Hmm, I've just remembered that for that particular citation I typed in the date as March 2nd, it wasn't picked up automatically (manually adding a report).
    Using Harvard.
  • which Harvard? There are many, many versions.
Sign In or Register to comment.