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?

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.

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.

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.

Now* grief.

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

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.

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.

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.

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).

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.

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?)

Re* your second para. Commuting and the ride is rough.

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.

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.