Почему GtkCalendar считает месяцы с 0?

Это целое обсуждение, включающее или исключающее. Вероятно, они использовали систему для подсчета количества прошедших месяцев.

Например, если вы скажете, что прошел 1 месяц, вы будете во втором месяце года. Поэтому, если вам нужна программа для подсчета количества прошедших месяцев и вы используете систему 1-12, она сообщит, что вы находитесь в месяце 1 (январь), а не в том, что прошло 0 (январь) месяцев, и вам нужно будет выполнить предварительную проверку дополнительная функция, чтобы определить, сколько времени прошло.

Так же, как в «Головоломке мысли» в Chrono Trigger, http://www.youtube.com/watch?v=Ll1uAla90BU&t=13m42s , в зависимости от того, как вы рассчитываете, если вы считаете от начать или если вы считаете, когда вы закончите, это может быть невероятно вводящим в заблуждение.

Таким образом, для кодирования легче начать с 0, на диаграмме вы считаете до трех, но на первом рисунке это всего лишь 2 полных цикла (месяца), а во втором Вы считаете до 3, но начинаете с 0, добавляя до 3 полных месяцев.

Так же каждый подсчитывает, сколько им лет, вы начинаете с 0 и переходите к 1 после того, как прошел год.

Что касается того, почему они также не делали это в течение многих дней и лет. Я полагаю, что подсчет по дням раздельный из-за разного количества дней в месяце, это также затруднило бы подсчет того, сколько месяцев прошло, если вы используете количество дней. и вы можете получить точный подсчет прошедшего года, если посчитаете, сколько месяцев прошло, т. е. если вы подсчитали месяцы точно, вы можете точно посчитать годы, в году будет 12 полных месяцев, начните считать с 0 и после того, как вы Если нажать 12, вы вернетесь к 0, поэтому числа будут 10 11 0 1 2 3 ... как на картинке ниже, если вы сосчитаете до 2, затем перезапустите -

[ 1110] В любом случае, вкратце, программисты просто делали то, что им было легче.

Документ для GtkCalendar: http://developer.gnome.org/gtk/2.24/GtkCalendar.html

Общее объяснение для нуля на основе:

Использование нуля, чтобы начать считать, на самом деле трюк оптимизации от программистов ассемблера. Вместо того, чтобы назначать 1 в регистр подсчета, они XOR'или регистр с собой, что было немного быстрее в циклах ЦП. Это означало, что подсчет начнется с 0 и будет всегда соответствовать длине элементов, исключая последний.

Кроме того, использование нуля также популярно в арифметике указателей, где вы будете использовать один базовый указатель, указывающий на некоторую выделенную память, плюс второй указатель, который будет со смещением от этого базового указателя. Здесь использование нулевого значения имеет большой смысл для указания смещения к основанию блока памяти. (Общая логика массива, как правило, представляет собой базовый адрес плюс смещение x размера записи.)

И числа месяцев, начинающиеся с нуля? Часто во многих средах программирования данные рассчитываются как количество дней, начиная с некоторых данных по умолчанию. 31 декабря 1899 года является популярной датой, хотя в качестве базовой даты использовалось множество других дат. Все остальные даты смещены относительно этой базы и будут сохранены как одно целое число. Фракции будут использоваться для указания часов, минут и секунд, где 0,25 будет 24/4 = 6 часов. Таким образом, чтобы преобразовать дату в реальную дату, все, что требуется от среды, - это преобразовать это число в реальную дату.

Тем не менее, комбинация массивов, основанных на нуле, и значений месяца, основанных на 1, создает проблему. Чтобы получить название месяца 9, вам нужно получить элемент 8 из массива month. Некоторые разработчики были бы рады уменьшить номер месяца, прежде чем получить его название. Другие предпочли изменить месяц на ноль, поскольку люди просто хотят знать имя, а не номер. Это личное мнение.

Более того, есть более чем причина, по которой можно подумать, что что-то не так с датой / календарем:

• Удивительные основы (1900 как годовая база в дате, по общему признанию для устаревших конструкторов; 0 как база месяца в обоих)
• Изменчивость - использование неизменяемых типов значительно упрощает работу с действительно эффективными значениями
• Недостаточный набор типов: приятно иметь разные даты и календарь. Вещи, но разделение «локальных» и «зонированных» значений отсутствует, как и дата / время против даты против времени
• API, который приводит к уродливому коду с магическими константами вместо четко названных методов
]
• API, который очень сложно рассуждать - все дело в том, когда что-то пересчитывается и т. Д.
• Использование конструкторов без параметров по умолчанию «сейчас», что приводит к сложному тестированию кода