Change Details

See PHI1848. When a page is printed, the user's display date and time format are used. These may look like this: > Fri, Aug 14, 11:20 AM > Sep 10 2019, 6:46 AM The former format is used when the year is the same as the current year. The latter format is used if the date is in a previous year. Neither format is unambiguous, so it may not be possible to precisely interpret the dates in a hard copy of the page: - The "same year" format is ambiguous in a printed document without external knowledge of the year the page was generated. However, often the document will have a "Printed on MM/DD/YYYY" sort of header which mitigates this somewhat. - The time format is ambiguous in a printed document without external knowledge of the viewer's timezone settings. --- I plan to use an unambigous, absolute, context-free print rendering to resolve this, e.g. make all dates render like this in printed documents: > 2020-09-10 06:46:22 UTC-9 Some alternatives implementations: - This could be done via date/time settings, but then you'd have to configure it and it would make normal use a little worse (timezone information is pretty much useless in normal use). - We could do this, but render ISO 8601. I think this trades off human readability a little too much: using a slightly more readable format seems much better for the "normal human user" use case and not meaningfully worse for the "archival" use case. - We could do this, but render UTC. As above, I think this trades off human readability a little too much. The one thing I don't like about this approach is that it makes the web rendering and the print rendering different in a subtle, non-obvious way. In this case, I think the benefits outweigh this cost.

See PHI1848. When a page is printed, the user's display date and time format are used. These may look like this: > Fri, Aug 14, 11:20 AM > Sep 10 2019, 6:46 AM The former format is used when the year is the same as the current year. The latter format is used if the date is in a previous year. Neither format is unambiguous, so it may not be possible to precisely interpret the dates in a hard copy of the page: - The "same year" format is ambiguous in a printed document without external knowledge of the year the page was generated. However, often the document will have a "Printed on MM/DD/YYYY" sort of header which mitigates this somewhat. - The time format is ambiguous in a printed document without external knowledge of the viewer's timezone settings. --- I plan to use an unambiguous, absolute, context-free print rendering to resolve this, e.g. make all dates render like this in printed documents: > 2020-09-10 06:46:22 UTC-9 Some alternatives implementations: - This could be done via date/time settings, but then you'd have to configure it and it would make normal use a little worse (timezone information is pretty much useless in normal use). - We could do this, but render ISO 8601. I think this trades off human readability a little too much: using a slightly more readable format seems much better for the "normal human user" use case and not meaningfully worse for the "archival" use case. - We could do this, but render UTC. As above, I think this trades off human readability a little too much. The one thing I don't like about this approach is that it makes the web rendering and the print rendering different in a subtle, non-obvious way. In this case, I think the benefits outweigh this cost.

See PHI1848. When a page is printed, the user's display date and time format are used. These may look like this: > Fri, Aug 14, 11:20 AM > Sep 10 2019, 6:46 AM The former format is used when the year is the same as the current year. The latter format is used if the date is in a previous year. Neither format is unambiguous, so it may not be possible to precisely interpret the dates in a hard copy of the page: - The "same year" format is ambiguous in a printed document without external knowledge of the year the page was generated. However, often the document will have a "Printed on MM/DD/YYYY" sort of header which mitigates this somewhat. - The time format is ambiguous in a printed document without external knowledge of the viewer's timezone settings. --- I plan to use an unambiguous, absolute, context-free print rendering to resolve this, e.g. make all dates render like this in printed documents: > 2020-09-10 06:46:22 UTC-9 Some alternatives implementations: - This could be done via date/time settings, but then you'd have to configure it and it would make normal use a little worse (timezone information is pretty much useless in normal use). - We could do this, but render ISO 8601. I think this trades off human readability a little too much: using a slightly more readable format seems much better for the "normal human user" use case and not meaningfully worse for the "archival" use case. - We could do this, but render UTC. As above, I think this trades off human readability a little too much. The one thing I don't like about this approach is that it makes the web rendering and the print rendering different in a subtle, non-obvious way. In this case, I think the benefits outweigh this cost.