Closed Bug 1509096 Opened 6 years ago Closed 2 years ago

Global option to use ISO 8601 date format

Categories

(Thunderbird :: Preferences, defect)

Product:
Thunderbird
Component:
Preferences
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: vladimir-csp, Unassigned, Mentored)

References

Details

(Whiteboard: [lang=c++])

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:63.0) Gecko/20100101 Firefox/63.0 Steps to reproduce: Upgraded Thunderbird. Actual results: Thunderbird and Firefox no longer get en_DK locale data regarding time formats from the system, but from CLDR, which does not contain ISO 8601 date format. Thus the point of en_DK locale was negated. Expected results: This report is a continuation of #1426907 Please add a global option to Thunderbird (and Firefox) to use ISO 8601 date and time formats, so that any localized date format abominations can be overridden in a fast, easy and user-friendly way. To quote two of the best messages from #1426907: gessel@blackrosetech.com: > ISO-8601 is /the/ global standard for date-time. There is not another one. > There's no competition. Adding an ISO-8601 option will not open the door to > requests to add radio buttons for other standards because they're aren't any > other global standards for the unambiguous representation of date and time. > Enabling easy selection of ISO-8601 simply makes a standards compliant > experience something normal users can achieve, rather than an absurdly > complicated, fragile exercise in root-level config file hacking. jflorian: > Well said. I just want to add the MSF should take the lead here and not just with TB. > Please make this simple, if not the startup default. It's time for the world to end the > absurdities with the ludicrous number of time formats and the ridiculous complexities they > impose on software and its users. ISO-8601 is the global standard. Let's embrace it and > let the other formats fail for what they really are, relics of an un-unified world. Those who > wish to cling to the past should be the ones making herculean efforts, not those who want > to improve the situation.
I would also like to see an option to specify ISO 8601 date and time formats. To be more clear, the more readable YYYY-MM-DD HH:mm format would be my preference rather than the YYYY-MM-DDTHH:mm:ss format.
> To be more clear, the more readable YYYY-MM-DD HH:mm format would be my preference rather than the YYYY-MM-DDTHH:mm:ss format. So, you would prefer to NOT use ISO 8601 date/time format, because ISO 8601 is "YYYY-MM-DDTHH:mm:ssDTZ". That's a totally valid request, and I'm open to patches that introduce that as a regional date/time format preference, but we have to be specific here - 1) You're not asking for ISO 8601 but a custom, human-readable, format "YYYY-MM-DD HH:mm:ss TZ" 2) This is *not* an internationalization/localization issue, since the format is not used in any region/locale, and the request is to enable it irrelevant of region/locale.
(In reply to Zibi Braniecki [:gandalf][:zibi] from comment #2) > > To be more clear, the more readable YYYY-MM-DD HH:mm format would be my preference rather than the YYYY-MM-DDTHH:mm:ss format. > > So, you would prefer to NOT use ISO 8601 date/time format, because ISO 8601 > is "YYYY-MM-DDTHH:mm:ssDTZ". > > That's a totally valid request, and I'm open to patches that introduce that > as a regional date/time format preference, but we have to be specific here - > > 1) You're not asking for ISO 8601 but a custom, human-readable, format > "YYYY-MM-DD HH:mm:ss TZ" > 2) This is *not* an internationalization/localization issue, since the > format is not used in any region/locale, and the request is to enable it > irrelevant of region/locale. 1) The form without the T is valid ISO 8601, not custom. Adding the TZ as you did is probably a good option for an international format. Also, valid is YYYYMMDDHHmmss which is taking readability to the other extreme, meaning further from my preference. So, I prefer to use an ISO 8601 format, just a more readable one. The one you gave as an example is the format from an earlier version of ISO 8601. A even newer version is expected soon next year. 2) This format is used internationally so therefore it is and can be used in any region. The feature request is to have this format option available in spite of any other regional preferences which may be set. You are correct, this should be an option to enable irrelevant of region/locale. I just wanted to be clear which of the ISO 8601 formats I preferred. I wish to note the irony in the fact that the email alert I received for your response used a format extremely similar to what I identified, in fact your improved suggested format with the TZ. "Comment # 2 on Bug 1509096 from Zibi Braniecki [:gandalf][:zibi] at 2018-11-21 14:14:47 PST "
> 1) The form without the T is valid ISO 8601, not custom. Can you provide a source for that? I did some, rather short, research and all I can find indicates that ISO 8601 uses `T` as a separator between date and time portion in case both are presented together. I could not find anything suggesting that a space is a valid separator. > 2) The feature request is to have this format option available in spite of any other regional preferences which may be set. Yes, we agree. I was just pointing out that it's the interesting cross from the internal code organization POV since so far all of our date/time formatting code has been unified as part of the intl module, but this spans outside of it and will likely be encoded as an option for OSPreferences (part of intl) to *ignore* locale specific date/time and format using a custom pattern. It's an interesting cross that has been also part of the conversation in the ECMA402 (JS Intl) community because patterns, by defition, are not internationalizable. For the intl version of patterns, Unicode uses skeletons such as "yMD" or "yMDhd" which then get internationalized into patterns specific for the region. So when someone asks for a particular pattern to format the date into, they're stepping outside of intl domain, and into data formatting domain. It's not irrational, it's just a bit outside of how we usually think of things :)
The source I used to determine the T is an optional designator for the ISO 8601 date time format is wikipedia which references the ISO 8601 standard. https://en.wikipedia.org/wiki/ISO_8601#cite_note-32 "ISO 8601:2004(E)". ISO. 2004-12-01. "4.3.2 NOTE: By mutual agreement of the partners in information interchange, the character [T] may be omitted in applications where there is no risk of confusing a date and time of day representation with others defined in this International Standard." I guess this could mean no space between the date and time, rather than the oft interpreted substitution of a space for the omitted T.
> I guess this could mean no space between the date and time, rather than the oft interpreted substitution of a space for the omitted T. Yep, that sounds like "YYYY-MM-DDHH:mm:ss" pattern. We may want to look up if there's a name for the "YYYY-MM-DD HH:mm:ss" pattern to use in the UI for this feature.
I also found this from RFC 3339 from 2002: https://tools.ietf.org/html/rfc3339#section-5.6 5.6. Internet Date/Time Format . . . NOTE: ISO 8601 defines date and time separated by "T". Applications using this syntax may choose, for the sake of readability, to specify a full-date and full-time separated by (say) a space character. also from: https://devtipscurator.wordpress.com/2017/01/08/powershell-datetime-formatting-demystified/ Microsoft has in .NET three similar formats predefined, but as usual, none are exactly the same; These are accessible in multiple ways when specifying format such as powershell's get-date function code description example o Round-trip date/time pattern 2017-01-08T11:00:00.4360943-05:00 s SortableDateTimePattern (based on ISO 8601) using local time 2017-01-08T11:00:00 u UniversalSortableDateTimePattern using the format for universal time display 2017-01-08 11:00:00Z The only form without the T uses UTC or "Z"ulu or "Z"ero time zone exclusively. In my search, I found plenty of examples of the proposed format in use, but not identified. An example from Thunderbird that I am now seeing in the message list date column, I see "2018-11-21 08:09" and in the header portion of view pane I see "2018-11-21 13:09 +0000". I assumed the date column to be my local time which is confirmed by the zero timezone offset indicated. Knowing that I am in +0500 from UTC +0000 that seems correct. If the proposed format were to be "2018-11-21 08:09 +0500 EST" or just "2018-11-21 08:09 +0500" I'd be happy with that as well. I am happy with my current configuration, but it took more work than it should have, and may change in a future update to Thunderbird. The way I read this format when truncated is to assume local timezone. I don't think accuracy to seconds is necessary in the message list display or the normal headers view for routine usage. The expanded all headers view provides the seconds now if I should need to see them. And, there is always view message source for full detail, and then readable format is not really a concern.
I was not able to find a name for the format which uses a space when omitting the T from ISO 8601 date time format. I see the date format frequently referred to as the international format. The time portion being 24 hour is more internationally used anyway. If one were to call it international display format, I think it would be understood.
I too have always understood the space separator to be an optional substitute for the 'T' and would only cite the same references already given. I do think the space-separated version better for humans. In fact, I'm curious why/how the standard justified the 'T', but I guess that's irrelevant here.
I also got here from bug 1426907. Zibi is correct that ISO 8601 (2004) prescribes a "T" between date and time. Although shollingsworth+mozilla's rebuttal is indeed quoted verbatim from subsection 4.3.2 of the standard, subsection 3.4.1 implicitly proscribes substituting that "T" with a space: > Unless explicitly allowed by this International Standard the character “space” shall not be used in the representations [of date and time of day]. If I had to guess, I'd say spaces are proscribed because they're bad news in computer data, as they're commonly used to distinguish words (in the operating system sense of "word"). I nevertheless prefer to see a space between date and time of day. It's definitely easier to read. What I would keep from ISO 8601 is its prescription of ordering from left to right the most significant unit of time (year) to the least (minute or second), as we do with numbers generally; its allowance for leading zeros; and its separation of date units with hyphens ("-") and time of day units with colons (":"). Such a format is sortable and universally unambiguous to read. In conclusion, Zibi is right to say that what I and others want is _not_ ISO 8601 conformance but a date and time format that's readable and chronologically sortable. ISO 8601 would give us that if not for its prosciption of spaces. Thanks for being so patient and responsive with the Thunderbird user base, Zibi.
Thank you for your analysis! This is very valuable! Based on it, I'd recommend to: 1) Select a name. Yes, it's one of the hardest problems in computer science, but I believe we can do that! In particular, I naively believe that there *must* be some precedence. Windows? Android? MacoS? Someone must have use the format we're talking about and it must have some name. Let's find it! 2) Write the patches. I'm happy to mentor anyone willing to dive into this, but I will not have time to write the patches myself. Notice: It will require some C++ knowledge, ability to build Firefox or Thunderbird, and I will force you to write docs and tests because I like my module clean. Consider yourself warned ;) 3) Once we have (1) and (2) adding the UI to Thunderbird should be trivial.
Mentor: gandalf
Keywords: good-first-bug
RFC 3339's "Internet Date/Time Format", quoted above by gshollingsworth+mozilla, requires UTC time ± offset. We don't want that, since displaying non-local time would inconvenience the user or induce error. But if Thunderbird were to do the math itself, by adding the offset to show local time, the resulting time format would technically be _offset RFC 3339_. I recommend calling it what it is, then, _offset RFC 3339 (local)_, unless a conventional name for this format can be found. Omitting the final unit of time (seconds) would produce _truncated offset RFC 3339_. RFC 3339 2018-11-28 03:30:05-04:00 offset RFC 3339 (local time) 2018-11-27 23:30:05 truncated offset RFC 3339 2018-11-27 23:30
I misunderstood local offsets in RFC 3339. The partial time is always local, and the offset is a contrivance, not arithmetic. To contrive universal time (Z), we subtract the signed offset from the partial time. For instance, 2018-11-30 03:30:05-04:00 <=> 2018-11-30 07:30:05Z 2018-11-30 03:30:05+04:00 <=> 2018-11-29 23:30:05Z (Blinks.) That undermines my Comment 12. As for naming conventions, GNU's `date' command has options for RFC 3339 formatting. The option `--rfc-3339=seconds' would produce $ date --rfc-3339=seconds 2018-11-30 03:30:05-04:00 where 03:30:05 is local time. See the man page for `date'. I submit that Thunderbird date options ought to include RFC 3339 full time 2018-11-30 03:30:05-04:00 RFC 3339 partial time 2018-11-30 03:30:05 RFC 3339 partial time to the minute 2018-11-30 03:30 _Full-time_ and _partial-time_ are the specific terms used in RFC 3339 to denote a time of day portion with and without offset, respectively.

I recently posted a comment for bug 1426907, wherein I offered two fixes to deal with date/time formatting problems in Thunderbird.

The second fix I describe there directly addresses this issue.

Zibi, FCqzsFMrsieN3hpkERKg; vladimir-csp; et al. This was a very informative and well written bug report. It is interesting that en_DK formatting was (before all this mess began) not quite technically ISO 8601, rather closer to RFC 3339 partial time.

To my needs, FCqzsFMrsieN3hpkERKg's solution addresses all reasonable concerns: it yields an unambiguous, sort-able, internationally comprehensible date and time format that follows expected endian precedence.

I feel this is a justifiable complication to the UI superseding standard selection of localization and language as it permits selection of an international standard (or the slightly more human readable RFC derivation thereof), something which by intent crosses national borders and boundaries. Further, reading through the vast volume of bugs reported after the en_DK hack stopped working, they come from users in many countries using many languages and yet the most common complaint is finding it difficult to specify the ISO 8061-like date and time formatting they had previously struggled to achieve.

That users are willing to read through reams of bug reports and attempt rather arcane commands suggests that for at least some (perhaps many) users, this is a presentation modality of significance.

While I see the very generalized value of Jeff Harp's approach and would certainly be happy with it if it appeared, my inclination is to privilege the international standard.

(In reply to gessel@blackrosetech.com from comment #15)

Zibi, FCqzsFMrsieN3hpkERKg; vladimir-csp; et al. This was a very informative and well written bug report. It is interesting that en_DK formatting was (before all this mess began) not quite technically ISO 8601, rather closer to RFC 3339 partial time.

http://www.loc.gov/standards/datetime/iso-tc154-wg5_n0038_iso_wd_8601-1_2016-02-16.pdf
(older version, but probably still relevant)

My understanding is that the desired date/time format as discussed here is ISO 8601 with the following components, in order:

  • "YYYY-MM-DD": Calendar date, complete representation, extended format (section 4.1.2.2)
  • " ": T omitted (section 4.3.2)
  • "hh:mm:ss": local time, complete representation, extended format (section 4.2.2.2).

Personally, I do think calling the format ISO 8601 would match user expectations. I'd happily use it whatever it is called, though. :)

-Corey

I am asking the CLDR folks for help with all of this. Please see my new ticket:
https://unicode.org/cldr/trac/ticket/12027
"CLDR should support (some variants of) ISO-8601 date formats."

(In reply to Len Weisberg from comment #17)

I am asking the CLDR folks for help with all of this. Please see my new ticket: https://unicode.org/cldr/trac/ticket/12027

Doesn't seem like much has happened there

Keywords: good-first-bug
Whiteboard: [lang=c++]

(In reply to Zibi Braniecki [:zbraniecki][:gandalf] from comment #11)

Thank you for your analysis! This is very valuable!

Based on it, I'd recommend to:

  1. Select a name. Yes, it's one of the hardest problems in computer science,
    but I believe we can do that! In particular, I naively believe that there
    must be some precedence. Windows? Android? MacoS? Someone must have use
    the format we're talking about and it must have some name. Let's find it!

  2. Write the patches. I'm happy to mentor anyone willing to dive into this,
    but I will not have time to write the patches myself. Notice: It will
    require some C++ knowledge, ability to build Firefox or Thunderbird, and I
    will force you to write docs and tests because I like my module clean.
    Consider yourself warned ;)

  3. Once we have (1) and (2) adding the UI to Thunderbird should be trivial.

Hi Zibi,

Are you still wiling to mentor the bug?
if yes, could you point me out to where I could start and maybe help me out by breaking this bug into small steps :)

Sadly, https://unicode.org/cldr/trac/ticket/12027 is 404, it seems that wasn't taken up.

As to naming, note that the ls option --time-style=long-iso yields exactly what seems to be the general preference:

gessel@dg-B300G5:~$ ls -l --time-style=long-iso
total 60
drwxr-xr-x  4 gessel gessel 4096 2016-08-30 23:00 Anki
drwxr-xr-x  2 gessel gessel 4096 2020-05-23 20:18 Desktop
drwxr-xr-x  2 gessel gessel 4096 2020-05-22 20:13 Documents
drwxr-xr-x  2 gessel gessel 4096 2020-05-23 20:59 Downloads

Therefore I'd argue, that like Gnu before, the name should be "long-iso"

https://www.gnu.org/software/coreutils/manual/html_node/Formatting-file-timestamps.html

  • 'full-iso’

    List timestamps in full using ISO 8601-like date, time, and time zone components with nanosecond precision, e.g., ‘2002-03-30 23:45:56.477817180 -0700’. This style is equivalent to ‘+%Y-%m-%d %H:%M:%S.%N %z’.

    This is useful because the time output includes all the information that is available from the operating system. For example, this can help explain make’s behavior, since GNU make uses the full timestamp to determine whether a file is out of date.

gessel@dg-B300G5:~$ ls -l --time-style=full-iso
total 60
drwxr-xr-x  4 gessel gessel 4096 2016-08-30 23:00:37.180162000 +0300 Anki
drwxr-xr-x  2 gessel gessel 4096 2020-05-23 20:18:04.940169342 +0300 Desktop

  • ‘long-iso’

    List ISO 8601 date and time components with minute precision, e.g., ‘2002-03-30 23:45’. These timestamps are shorter than ‘full-iso’ timestamps, and are usually good enough for everyday work. This style is equivalent to ‘+%Y-%m-%d %H:%M’.

gessel@dg-B300G5:~$ ls -l --time-style=long-iso
total 60
drwxr-xr-x  4 gessel gessel 4096 2016-08-30 23:00 Anki
drwxr-xr-x  2 gessel gessel 4096 2020-05-23 20:18 Desktop

*‘iso’

List ISO 8601 dates for non-recent timestamps (e.g., ‘2002-03-30 ’), and ISO 8601-like month, day, hour, and minute for recent timestamps (e.g., ‘03-30 23:45’). These timestamps are uglier than ‘long-iso’ timestamps, but they carry nearly the same information in a smaller space and their brevity helps ls output fit within traditional 80-column output lines. The following two ls invocations are equivalent: '''

gessel@dg-B300G5:~$ ls -l --time-style=iso
total 60
drwxr-xr-x  4 gessel gessel 4096 2016-08-30  Anki
drwxr-xr-x  2 gessel gessel 4096 05-23 20:18 Desktop

It is my most sincere request that at least "long-iso" time and date formatting be provided as a completely independent option overriding any other locale or lcdr settings in Advanced->General->Date and Time Formatting:
[] Application locale:
[] Regional settings locale: (no apparently ignored)
[] long-iso format (YYYY-MM-DD HH:MM)

Deferring to Gnu's expertise and standard's setting concludes step 1: "name" - it is "long-iso" format. Now we just need some patches.

Unicode.org seems to have migrated to JIRA for bug tracking. The new URL seems to be https://unicode-org.atlassian.net/projects/CLDR/issues/CLDR-12027. Another relevant issue is CLDR-10014.

Ceterum censeo:

  • A display format following the ISO 8601 component ordering is desirable.
  • In the display format, separating date and time with a space instead of the T is also desirable, for readability.
  • Calling that either ISO 8601 or RFC 3339 is technically incorrect. Both support T as the only possible separator, and ISO 8601 also allows omitting the separator. The note in RFC 3339 “Applications using this syntax may choose, for the sake of readability, to specify a full-date and full-time separated by (say) a space character.” does not mean space is a valid separator for date-time, only that applications may choose to forgo using the date-time grammar production in favor of crafting a custom rule from full-date and full-time. It is implied that applications that do so necessarily lose some of the interoperability benefits.
  • Putting the technically incorrect name in high visibility software such as Firefox, Thunderbird, or GNU coreutils, leads to more confusion as to whether space is a valid separator in those standards.
  • Therefore, please call it “international date format” or “sensible date format” or “big-endian date format” or something, but do not refer directly to ISO 8601 or RFC 3339.

Paul Eggert says:

No, RFC 3339 explicitly allows the use of space. It says:

 NOTE: ISO 8601 defines date and time separated by "T".
  Applications using this syntax may choose, for the sake of
  readability, to specify a full-date and full-time separated by
  (say) a space character.

This paragraph was put into the RFC at my suggestion, precisely so that GNU
"date" output wouldn't have to contain that "T".

Tf you want GNU 'date' to output the 'T', you can use 'date --iso-8601=s'
instead of 'date --rfc-3339=s'. That's the point of having these two options for
GNU 'date'. If it weren't for this difference in behavior, GNU 'date' wouldn't
have needed a --rfc-3339 option in the first place, and we shouldn't change the
meaning of --rfc-3339 to eviscerate the whole point of the option.

Yuri's points are valid and would tend to suggest that the options for ls aren't consistent with the naming used in date. On my system:

 gessel@dg-B300G5:~$ date --rfc-3339=s
 2020-05-26 19:31:53+03:00

 gessel@dg-B300G5:~$ date --iso-8601=s
 2020-05-26T19:32:49+03:00

This seems fairly authoritative that the desired YYYY-MM-DD hh:mm representation is RFC 3339 compliant with respect to the space. Before adopting the nomenclature, adopting section 4.4's stern admonition against unqualified local time would be highly redundant in an inbox list, as it would usually be in a file list. Including TZ information would seem to contradict the spirit of section 5.2 and 5.4. Perhaps a revision to section 5.4 that specifically cites the highly redundant nature of lists of identical TZ offsets would add some clarity as gnu ls 'long-iso' is the desired format.

Note the 5.7's concluding paragraph is incorrect in light of changes included in ISO 8601-1:2019 ("24" is no longer permitted).

Paul Eggert does not believe omitting the time zone offset information is RFC 3339 compliant, so while a space between date and time is compliant, the desired format for the list is not.

As an additional reference, changeQuote calls "international format" this:

 Date: Wed May 27 2020 04:39:39 GMT+0300 (Arabian Standard Time)

But you can use changeQuote to configure reply in RFC 3339 format as %Y-%m-%d %h:%i%z:

 Date: 2020-05-27 04:39+0300

I do really like Yuri's "Sensible Date Format".

The addon ConfigDate enables showing headers with sender's time zone (not RFC 3339 compliant as it appends the TZ name where known (I like this myself)). I'm not sure why this isn't default - I usually know my timezone and am more interested in the sender's time zone.

This brings up another issue for Sensible Date Format to address: header formatting. My preference would be that SDF would format the folder view just as ls -l --time-style=long-iso does and for the same reasons. On windows it would be nice to remove the vestigial comma field separator:

Windows display (implies two fields, a date field and a time field):

 2020-05-26, 20:45

The list window in Sensible Date Format should show date and time as does the ls "long-iso" as:

 2020-05-26 20:45

I'm agnostic about what used to be the mail.ui.display.dateformat.today option "0" default (what happened to those prefs?)

In header representation, in preview pane and open message window, the "Date" header would be formatted to full RFC 3339 format with sender offset default:

 Date: 2020-05-27 05:22:00-0500

Appending the TZ code is a bonus for human readability. One could argue that prefixing the day of the week might also be useful information, despite the RFC 3339 redundancy argument. I'd argue that such details are best left as hooks that can be tweaked by restoring an options block to config:editor

How I'd configure it if I had the options:

 Date: 2020-05-27 05:22:00-0500 (CDT)

The default core reply format header style should be the same RFC 3339 compliant format as Date header representation in preview and message views: (the changeQuote plugin permits any desired variations).

Indeed the entire naming and specifying technically correct formatting process could also be fully obviated by adding the following options to edit:config:

Preference Name                             Status       Type        Value
mail.ui.display.dateformat.today            modified     string      %D %H:%i
mail.ui.display.dateformat.thisweek         modified     string      %m-%d, %D %H:%i
mail.ui.display.dateformat.default          modified     string      %y-%m-%d %H:%i
mail.ui.dateheader.dateformat.preview       modified     string      %y-%m-%d %H:%i%z
mail.ui.dateheader.dateformat.message       modified     string      %y-%m-%d %H:%i%z (%t)
mail.ui.dateheader.dateformat.reply         modified     string      %Y-%m-%d %H:%i:%s.%u%z (%T)

%Y = year, 4 digits ("1999")
%y = year, 2 digits ("99")
%m = month ("01" to "12")
%M = month, textual, English, 3 letters ("Jan")
%d = day of the month, 2 digits ("01" to "31")
%D = day of the week, textual, English, 3 letters ("Fri")
%H = hour, 24-hour format ("00" to "23")
%h = hour, 12-hour format ("01" to "12")
%i = minutes, ("0" to "59")
%s = seconds ("00" to "59")
%u = microseconds 
%A = "AM" or "PM"
%a = "am" or "pm"
%z = timezone offset from UTC ("+0300")
%t = timezone abbreviation, if known  ("AST")
%T = timezone name, if known ("Arabia Standard Time")

Then users can just configure ISO8601 compliant, RFC 3339 compliant or personal preference as they see fit without any "labels" being applied.

+1 to fully configurable formats by today/thisweek/default, + maybe thisyear. But bonus points if that uses standard placeholder designations as in strftime(3) and date(1).

(Also, no need to support 2-digit years. That subformat should have been left in 1998.)

(Also, RFC 5322 does not provide for time zone names,

Sorry for sending an unfinished comment. As I was saying, RFC 5322 Date header does not provide for time zone names, only offsets, and inferring a time zone from offset is generally not possible.

Providing edit:config user-formatting of time/date representations is the least controversial, most flexible, and most user-friendly way to alleviate the conundrum.

I, myself, like 2 digit year #s as a graphical representation - the millennium and century CE really aren't relevant to me and I'm not going to live to see the Y2.1k bug. There's no argument that the underlying data representation should be suitable for century transitions, but the on-screen representation can be efficient without confusion until ~2090-2110.

The coding difference to add a formatting placeholder for those of us that would prefer the abbreviated format is trivial. People who really want assurance they haven't accidentally spilled an energy drink on the hot tub controls can use %Y.

And, as originating time zone names are often known, %T seems like a user-friendly and useful feature. If it isn't known, omit an output.

Time and date is meaningful and useful in email. Giving the users the option to configure it to their preference seems like a very user-friendly thing to do.

Given the deference to CLDR, why not embrace Unicode Locale Data Markup Language (LDML) Part 4, edited by Peter Edberg and other CLDR committee members. In particular adopting the recommendations of section 8, Date Format Patterns as I suggested above as configurable variables that when defined explicitly override whatever formula Thunderbird defaults to in setting date format patterns. The variation from my suggestion would be full enumeration of the pattern fields and Date Field Symbol Table.

https://unicode.org/reports/tr35/tr35-dates.html#Date_Format_Patterns

In particular, the era field, G, would fully alleviate any confusion that might arise for regular time travellers.

For example, this is lovely:

Pattern                               Result (in a particular locale)
yyyy.MM.dd G 'at' HH:mm:ss zzz        1996.07.10 AD at 15:08:56 PDT

Hi all. In bug 1509096 :dminor refactored our code to support custom patterns for date/time styles. In bug 1509096 comment 182 I documented how to test it. Can someone confirm whether it allows you get the desired behavior? We can work on UI changes to make such preferences setting easier later.

(In reply to Zibi Braniecki [:zbraniecki][:gandalf] from comment #28)

Hi all. In bug 1509096 :dminor refactored our code to support custom patterns for date/time styles. In bug 1509096 comment 182 I documented how to test it. Can someone confirm whether it allows you get the desired behavior? We can work on UI changes to make such preferences setting easier later.

Correct link: bug 1426907 comment 182

Severity: normal → S3

(In reply to gshollingsworth+mozilla from comment #29)

(In reply to Zibi Braniecki [:zbraniecki][:gandalf] from comment #28)

Hi all. In bug 1509096 :dminor refactored our code to support custom patterns for date/time styles. In bug 1509096 comment 182 I documented how to test it. Can someone confirm whether it allows you get the desired behavior? We can work on UI changes to make such preferences setting easier later.

Correct link: bug 1426907 comment 182

With that fixed, Is there anything left for us to do?

Flags: needinfo?(mkmelin+mozilla)

I think it's all done. Documentation can be found at https://support.mozilla.org/en-US/kb/customize-date-time-formats-thunderbird

Status: UNCONFIRMED → RESOLVED
Closed: 2 years ago
Flags: needinfo?(mkmelin+mozilla)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.