Title Text:Neither group uses iso 8601 because the big-endian enthusiasts were all at the meeting 20 years ago.

Origin:https://xkcd.com/2562/

https://www.explainxkcd.com/wiki/index.php/2562:_Formatting_Meeting

格式化会议

http://xkcd.in/comic?lg=cn&id=2562

在美国，通常以月/日/年的格式以数字形式书写日期——2/3/22 表示 2022 年 2 月 3 日（当日期明显在当前时间附近时，通常会省略世纪）。在欧洲，通常的顺序是日/月/年– 所以 2/3/22 是 2022 年 3 月 2 日。

“本地化”是软件中使用的一种技术，用于使其接受输入并以用户所在位置最自然的格式显示输出。例如，在美国，数字使用逗号“,”来分隔千位和小数点“。” 分隔十进制值，而在欧盟的大部分地区则相反。文本输出将被翻译成当地语言。当然，这也包括以本地格式显示日期，如上所述。本地化还可能包括在该地点采用税法，例如在为英国采用为美国制造的税务软件时。

这部漫画中的笑话是，在同一个显示器上显示了两个日期，与有关本地化的会议有关。美国团队的会议日期本地化为美国格式，而欧盟团队的会议日期本地化为欧洲格式，并且这两个日期（大约相隔一个月）的格式恰好相同（有 64 个这样的配对日期，只要其中一个月份的日期介于 1 和 12 之间并且不等于另一个假定的月份）。Cueball需要解释说，欧洲会议将比美国会议晚一个月，以避免由于模棱两可而造成任何混乱。这很讽刺，因为本地化的目的是减少这种混乱。

也延伸到标题文本的进一步解释是，这些小组可能应该在同一天开会。但即使是本应解决这些问题的委员会也把这件事搞砸了。Cueball 可能是在“解释”交错的方法来掩盖这两个小组已经以完全不同的方式阅读会议日期。

ISO-8601（即国际标准化组织自 1988 年颁布的标准编号 8601）指定的日期格式为 YYYY-MM-DD（例如 2021-12-31），这导致日期按时间顺序列出当按字符串排序时。ISO 格式称为“ big-endian ”，指的是日期（年份）中最重要的单位在前。相反，欧洲格式是“ little-endian ”，因为前端值代表日期可以传达的最佳区别 – 特定日期。美式格式是“中端””，或者偶尔是“混合端”，因为第一个给出的值既不是最重要也不是最精确的值。

在上面，“值组”通常不会在内部检查“字节序”，但常规数字也通常用左侧的最大位值写入 – 例如，2021中的前 2是千位——尽管这个约定是大端还是小端取决于这些数字的书写系统是在从左到右还是从右到左文本的上下文中。字节序的概念最常用于参考存储顺序，无论是不可分割的二进制位还是由连续值组构成的值。成对的十六进制值通常以大端“数字”顺序单独表示，其中不需要按位区分，但了解系统是否以大端或小端包装存储多字节值很有用，即是否值 0x01 0x02（值 1 和 2，单独）被视为值 258 (0x01*256 + 0x02*1) 或 513 (0x01*1 + 0x02*256)。（这个词的灵感来自Jonathan Swift 的故事关于一场应该切入煮鸡蛋结局的战争，这是许多其他情况的有用比喻，在这些情况下，对一种或另一种做法的完全相反的自我辩护可能导致坚持模糊的原则，而不是就统一的决议达成一致。）这标准也在1179: ISO 8601中被提及，并在1340: Unique Date中使用。

标题文本中的笑话是，似乎有些人试图解释格式不正确的日期，就好像它以更 ISO-8601 格式的“Y/M/D”表示。他们将日期读取为3 月 22 日20月 2 日，因此他们已经在将近 20 年前参加了会议。除非会议的公告是提前 2 年发布的，否则这些参与者会从遥远的未来的公告中选择日期，这是一个悖论。但是，对日期的严格解释会使其不正确：ISO-8601 格式指定四位数的年份（这也避免了假设世纪）、两位数的月份和两位数的天数。因此“2/3/22”不能按规范是 ISO-8601 日期，因为“2”只能呈现为“0002”，而“3”必须是“03”。即使在违反 ISO-8601 的情况下省略了前导零，年份也会变为Year 2，而不是 Year 2002。由于标准始终在第一个字段中使用 4 位“YYYY”格式，并且没有常见格式使用 YYYY-DD -MM，任何用 ISO-8601 编写的日期都很容易识别，并且（相对而言）可以明确解释为 YYYY-MM-DD。写成 YM-DD 或其他扭曲形式的日期应被视为格式不正确和不明智。