Комментарии 120
Полезная привычка объявлять тип данных (формат ячейки в терминологии Excel) раньше, чем пытаться что-то в неё вводить, избавит от необходимости совершать столь увлекательные исторические экскурсы. Сильная типизация рулит даже в таблицах.
Формат ячейки в Excel это не то же самое, что тип данных значения ячейки. Очень много ошибок из-за непонимания этой простой вещи. Формат показывает, как данные будут отображаться. А тип данных показывает, как данные будут храниться.
А как пользователю можно задать тип данных, кроме как через выбор формата? Терминология там, конечно, слегка шизофреническая ("text" в качестве одного из типов "number format", ага), но по сути-то так оно и есть: выбираем text - никаких преобразований вводимого не будет, выбираем number - будет приводиться к числовому типу, а не к дате, и т.п. По факту в списке "форматов" просто перемешаны типы данных и собственно форматы.
Формат ячейки может и влияет на вводимые данные и тем более на тип ячейки, но не прямолинейно. Тип данных ячейки можно вроде задать через программирование в VBA и иногда явно: если строку начать с апострофа, то это будет строка (не включающая начальный апостроф), и т.д. Но формат ячейки это формат вывода, а не формат хранения.
Ну если мы про внутреннее устройство, то согласен. Но для пользователя самый очевидный (а иногда и единственный) способ повлиять на тип - задать формат. И в списке "форматов" есть и комбинации формата с типом (разные представления чисел, короткая или длинная дата), и собственно тип (текст). Методика DDD с её ubiquitous language горько плачет в сторонке, но что поделать.
а еще в глубине настроек есть волшебная галочка "точность как на экране"
иногда доводящая до предынфарктного состояния)
А для профилактики действий особо одарённых пользователей надо еще и проверку данных поставить с отклонением ввода недопустимых данных.
Тут всё зависит от последовательности, в этом и отличие. Если сначала (перед вводом) задать формат, то он отработает как тип данных. Excel сразу будет знать как и что применить и не будет "умничать". Если ввёл а потом формат, ну... ожидаемо Excel пытается "помочь")))
тип данных показывает, как данные будут храниться.
Не только. Ещё — интерпретироваться при вводе.
Как будут данные интерпретироваться при вводе, скорее показывает формат ячейки, а не тип данных. Тип данных — это тип ранее введенного значения.
В ёкселе эти понятия тесно взаимосвязаны. (Вы уж звиняйте, но я на формате XLSX целую стаю собак съел.)
Осталось провести двойной слепой эксперимент. )
Но результаты ещё от версии Экселя могут зависеть.
Формат XLSX здесь вообще ни причём, так как мы говорим о поведении оболочки (пользовательского интерфейса), а не о формате файла. Если Вы о записи в файл какими-то другими средствами, а не ручным вводом, то там, возможно, иначе.
Спасибо, последнее старался так делал чисто интуитивно, что бы избежать проблем. (А оказывается это необходимость, я и не задумывался)
Особенно это удобно при вставке из буфера обмена или там файла csv )
При импорте CSV можно указать типы данных для каждого столбца в мастере импорта, если Excel угадал неправильно (там открывается Power Query Editor).
При вставке - ну смотря откуда и что вставляем. Если из другой таблицы - то сначала задать типы/форматы там, потом вставить с форматированием. Если вообще из текста - задать всему текстовый формат, вставить, а потом задать правильные типы/форматы.
Как ниже правильно написали, Excel уметь готовить. Не бывает так, чтобы одновременно и "автомагическое" форматирование работало (что многим надо), и полный ручной контроль сохранялся (что тоже многим надо).
Это если у вас есть такая возможность.
А бывает софт, который сохраняет данные в Excel, создавая новый файл. И в некоторых случаях (например, если разработчики софта забыли про региональные настройки) данные может покорежить при первом же открытии.
Не менее полезная привычка - не трогать user input, пока user об этом не просил: ввел он 1/2+1 - так и сохраняй, а не "делай как лучше". А ведь в статье не затронут еще такой интересный момент, как, например, 0,25 и 0.25 (в разных региональных страндартах).
Ctrl-A, Number Format -> Text, и получаете ровно такое поведение. Сохраняете получившееся как шаблон по умолчанию - и получаете такое поведение по умолчанию.
При должном уровне сноровки, с гландами можно проделать много увлекательных кунштюков, но нормальным принято считать дефолтный способ их удаления, а не способ, которым тоже можно достичь искомого результата, пусть и приложив несколько больше усилий.
Подозреваю, что для бóльшей части ЦА Excel дефолтное автомагическое преобразование типов важнее ручного контроля, требующего больше усилий. Маловероятно, что аудитория Хабра с этой ЦА существенно пересекается, ну так аудитории Хабра доступно множество других инструментов.
Подозреваю, что для бóльшей части ЦА Excel дефолтное автомагическое преобразование типов важнее ручного контроля, требующего больше усилий.
Если основной ЦА считать профессионалов, которые используют Excel для работы с данными, то - да.
Но есть подозрения, что ЦА сильно шире и разнообразней.
Как раз наоборот, основная ЦА не профессионалы, а условный бухгалтер Мариванна, про которую я написал в комменте пониже. Которая ничего не сможет посчитать, если Excel за неё не преобразует введённый текст в числа или даты. А как это сделать самой вручную - она не знает и не хочет узнавать, потому что она не айтишник какой-нибудь, чтобы все эти ваши сложности знать :)
Давайте уже скажем честно.
Бухгалтер не сможет посчитать, потому что ей не платят за преобразование текста в числа или даты. Как это сделать самой вручную, она знает, однако её работодатель не оплачивает такой уровень компетенции. Именно поэтому она и говорит, что такие знания означают не просто бухгалтера, а бухгалтера-айтишника.
Ну, а пока работодателю нужен бухгалтер подешевле, он и работать будет попроще.
Давайте скажем честно. Бухгалтеру Эксель не нужен. Он сидит в специализированном софте. Да и дорого для 95% компаний покупать лицензию на софт который скорее всего не будет использоваться по назначению. Либре Офис поставят и всё.
Эксель нужен бухгалтеру, чтобы заниматься управленческим учётом и чтобы делать справки для других сотрудников.
Нуууууу, не могу с вами согласиться.
У нас бухгалтеру нужно было сравнить 2 таблицы, чтобы проверить что нет ошибок в налогооблагаемой базе. 2000 строк, она делала это руками.
Попросила помочь, быстро набрасал сравнение через индекс/поискпоз. Это ещё раз повторилось, я ещё раз помог. На 3 раз сказал типа давай пробовать сама, у меня сейчас есть время, могу подключится и наблюдать, чтобы подсказать, у тебя 2 примера готовых, нужно сделать аналогично. Мне кинули абидку и отказались)
И это далеко не бухгалтер неделю назад пришедший с курсов.
Для предполагаемой Вами ЦА характерен ввод данных в формате "как есть", не задумываясь о внутреннем представлении о прекрасном у Excel, и неверное автоформатирование вызывает скорее ступор, чем удовлетворение.
Ага. Сначала вводишь 1.1, из этого получается первое января, ставишь формат "текст" и 1.1 превращается в 45658. Отлично!
Вот именно поэтому перечисленные действия надо выполнять в обратном порядке.
Так поздно выполнять в обратном порядке, когда уже ввел 1.1.
Так я своё (изрядно затянувшееся, не ожидал...) присутствие в комментах к этой статье и начал с рекомендации определять типы до того момента, как что-то начал вводить :)
Ну вот я и определил для себя тип "1.1" как текст или даже как число. Или "1-1". А эксель со мной не согласился. Мне каждый раз размышлять, может ли мой ввод быть преобразован в дату, и если да, то сразу форматировать ячейку, чтобы недайбох? Причем помнить, не только о том, что "12-12" окажется датой, а "13-13" останется как есть, но и о том, что "1-13" и "13-1" окажутся разными датами.
Если у Вас в столбце A - даты, так и задайте ему формат "дата", а если в столбце B - текст, то задайте формат "текст", чтобы он в даты не преобразовывал. А после того, как всем столбцам форматы назначите, заголовки там нарисуете и т.п., уже вводите в них данные.
Это понятно. Не держите айфон таким образом (с) Но лично я не знаю ни одного человека, который сначала форматирует столбцы, а потом начинает вводить данные. И виноват в этом в первую очередь сам эксель, который сам умеет форматировать числа в числа, текст в текст, даты в даты и всех к этому приучил. Проблема в том, что очень часто он принимает за дату то, что датой не является.
Так поздно выполнять в обратном порядке, когда уже ввел 1.1.
Как говорится:
— Доктор, когда я делаю так (показывает), мне больно!
— Это элементарно, больной: не делайте так!
С датами в Excel генетическая проблема. Если нужно открыть важный документ или раздать его для заполнения, то лучше использовать LibreOffice Calc.
Если этот документ был создан в Excel и/или предназначен для последующего открытия пользователями Excel - плохая идея. Список багов совместимости с форматами MS у LibreOffice ладно бы просто был огромный, так там ещё многие критичные вещи годами без движения.
Генетическая проблема там не с датами :)
Сдвиг на единицу ведь как раз и означает, что днём №1 было 31.12.1899, поэтому получается, что в документации всё правильно.
Днём №1 было 01.01.1900. 31.12.1899 это день номер 0. Но по какой-то дурости в Excel есть дата 29.02.1900, которой в жизни не было, поэтому если отсчитывать обратным счётом, то день №1 должен был бы выпасть на 31.12.1899.
кто-то из важных клиентов Excel, видимо, пользуется юлианским календарем
Как раз разница с 12 на 13 дней перескакивает с 1 марта 1900 года
29.02.1900 видимо вкрячили для какой-то компенсации
Вообще это было сознательное решение. Об этом писал Джоэл Спольски, вот тут можно почитать, как он был на ревью у Билла Гейтса, будучи разработчиком VBA (в том смысле что он его разрабатывал).
Фрагмент статьи
“I don’t know, you guys,” Bill said, “Is anyone really looking into all the details of how to do this? Like, all those date and time functions. Excel has so many date and time functions. Is Basic going to have the same functions? Will they all work the same way?”
“Yes,” I said, “except for January and February, 1900.”
Silence.
The f*** counter and my boss exchanged astonished glances. How did I know that? January and February WHAT?
“OK. Well, good work,” said Bill. He took his marked up copy of the spec
…wait! I wanted that…
and left.
Потом, когда ошибку обнаружили, можно говорить всё что угодно, что это не баг а фича и т.д. Но я не могу представить, чтобы во время разработки Excel кто-то ориентировался на юлианский календарь.
Её не "обнаружили", а сознательно добавили, для совместимости с более древним Lotus 123, где в свою очередь реализовали таким образом из-за того, что проверка через делимость на 4 (для чего нужно просто сравнить один бит) технически была предпочтительнее, перед его разработчиками стояли очень жёсткие технические ограничения
“So, it’s a bug in Lotus 123?”
“Yeah, but probably an intentional one. Lotus had to fit in 640K. That’s not a lot of memory. If you ignore 1900, you can figure out if a given year is a leap year just by looking to see if the rightmost two bits are zero. That’s really fast and easy. The Lotus guys probably figured it didn’t matter to be wrong for those two months way in the past. It looks like the Basic guys wanted to be anal about those two months, so they moved the epoch one day back.”
Я когда этот текст лет 20 назад прочитал, сразу изменил отношение к Гейтсу.
Я спрошу просто, логически. Если в истории не существует года номер 0, то почему должен появится день номер 0?
Вы не любите кошек Excel? Вы просто не знаете, как их его готовить!
Excel очень мощный инструмент. Но многие проблемы с Excel связаны с тем, что люди не понимают, где и как его можно использовать. Для себя выделил вот что:
Excel нельзя давать неквалифицированным пользователям. Неквалифицированным пользователям можно только дать табличку (какую-нибудь выгрузку из промышленного софта) для того, чтобы они эту табличку сохранили или распечатали.
Excel нельзя использовать для написания промышленного софта. Каждый, кто пишет на Excel, может использовать этот софт для себя или внутри небольшой команды.
При вводе данных в Excel требуется ручной контроль.
Все приводимые глюки Excel это не глюки, это его особенности. Опытный пользователь Excel их знает и либо обходит, либо использует. Для неопытных см.п.1.
но в 99% случаев:
- давайте всё что есть сведем в одну табличку...
- в пяти местах каждый раз править неудобно, давайте вставим формулу...
- давайте что выросло покрасим зеленым, что упало красным...
- давайте вместо 5 файликов сделаем один с пятью листами...
- тут сгруппируем, тут отфильтруем, тут объединим и выгрузим...
- ...
- ой, ну какая БД. Пять лет живем и ничего
Так это же прекрасно. Пользователи сами за 5 лет отработали и соответствующую предметной области и понятную им модель данных, и те фичи, которые реально нужны (в рамках возможностей Excel). Такая мегатабличка - половина ТЗ для нормальной автоматизации. А сопротивление переходу от Excel в основном вызвано небезосновательными опасениями, что вместо удобной таблички пользователям выкатят тормозного монстра, требующего по 10 кликов на операцию, которая раньше делалась в один.
Не нужно забывать, что в Excel пользователь одновременно может править и ТЗ, и реализацию. Промышленные решения, как правило, лишены такой гибкости.
подобная гибкость иногда приводит к замечательному результату, когда у вас файлик листов на 10 в одном 30к строк в остальных до 300 строк, колонок 20 -30 на каждом, и все это говно начинает жутко тормозить при любой операции с данными.
отдельно доставляло, что пользователи умудрялись добавлять невидимые обьекты на листы, отчего это реашьно нужный файл превращался в кучу г-на и начинал тормозить даже при скроллинге
Как будто с промышленным по с серверами за много денег не бывает точно также....
Для неопытных пользователей см.п.1.
https://habr.com/ru/articles/899100/comments/#comment_28153270
совсем недавно решал задачу загрузить в БД Mysql таблицу Excel на миллион строк с web интерфейсом на php что бы удобно фильтровать по параметрам и оказалось намного удобнее чем в самом excell работать
Так безусловно. А я вот потихоньку мегатаблички перевожу на Grist. Потому что более или менее сложная логика в Excel превращается в трудноподдерживаемый набор совершенно нечитабельных формул.
Я имел в виду случаи, когда вместо "партизанского" учёта в Excel внедряют ERP/CRM/т.п. Причём без учёта опыта той самой "партизанской автоматизации", в типовой конфигурации. В которой то, что раньше решалось путём добавления одной новой строки в таблицу, теперь требует последовательного открытия десятка карточек из разных разделов.
Так безусловно. А я вот потихоньку мегатаблички перевожу на Grist.
Я не смог найти там excel-like формулы, когда в одной колонке может быть и значение, и пять разных формул. Либо конвертируй всю колонку в формулы и задавай единую формулу, либо значения.
а на чем писали веб интерфейс? чистый php или какой-то фреймворк? и как фильтры реализовали?
Пользователи сами за 5 лет отработали и соответствующую предметной области и понятную им модель данных,
...а теперь нам на этом велосипеде из костылей лететь!
Есть кейс когда такая "самозарождающаяся мегатабличка" приносит лишь головную боль:
Скрытый текст
"Новый руководитель команды Williams «Формулы-1» Джеймс Воулз обнаружил, что руководители различных служб несколько лет использовали файл Excel с таблицей из более чем 20 тыс. строк..." https://habr.com/ru/posts/801897/
Ну иногда действительно ничего, если учитывать не только красоту, но и стоимость промышленного решения и дальнейшего сопровождения. Если потом в промышленном нужно будет что-то подправить, то это опять Х денег и времени. Тогда как в Excel-е опытный пользователь всё подправит за 5 минут.
На еще добавим объединения ячеек, «так ведь красивее».
Все приводимые глюки Excel это не глюки, это его особенности. Опытный пользователь Excel их знает и либо обходит, либо использует
Профессиональное ПО такого уровня должно каждый раз выдавать запрос "хотите конвертировать введённое число в день недели?" а не втихаря насильно всё править, вынуждая пользователя "изучать особенности ПО и обходить или использовать их".
Я бы убил Excel, если бы он меня каждый раз что-то спрашивал. Лучше один раз изучить, а потом действовать без подтверждений. Тем более что если заносишь таблицу из Х тысяч строк, это будет Х тысяч подтверждений? Спасибо, не надо. Использую Excel более четверти века, пока полёт нормальный.
Если вручную заносить тысячи строк, то никаких тысяч подтверждение не потребуется. Достаточно просто перенимать формат ячейки из предыдущей строчки (как это сейчас и происходит, хотя это не точно).
На этот случай нужно просто ввести чекбокс "больше не спрашивать".
Ручной ввод - источник ошибок. Часть из них можно легко предотвратить, включив "Проверку данных".
Если, например, величина должна быть от 2 до 3, а вы по ошибке вместо 2.01 введёте 201, то выскочит предупреждение. Это тот случай, когда предупреждения несут больше пользы, чем вреда.
По этой логике надо забрать браузер и командную строку (впрочем, командную строку-то как раз забрали).
Когда речь зашла про христианство, я было подумал, что эксель наловчился вести сквозную нумерацию абзацей библии или там псалтиря. Кто бы мог подумать, что 10:75 - это десять часов семьдесят пять минут!!! 43 мартобря.
="1/2"
Это просто портал в такую кроличью нору... Спасибо, не знал.
Навскидку:
="1/2"-"1/3" это сколько??
Скрытый текст
-28
Ок, сколько же тогда ="1/2"+"1/3" ?
Скрытый текст
Ну, смотря как посмотреть на это..
0:00:00 Время
91 406,00 ₽ Финансовый
04.04.2150 Краткий формат даты
4 апреля 2150 г. Длинный формат даты
91406,00 Числовой.
Хорошо, а как тогда получить 42?
Да, в экселе очень раздражает эта презумпция винов датнусти. Такое впечатление, что авторы следовали принципу "если это хотя бы теоретически может быть датой, то это дата".
Разделитель дробной части - запятая. Копируешь таблицу с двойной нумераций пунктов: 1, 1.1, 1.2, 1.3 и т.д. Эксель превратить это в дробные числа? Оставит как есть? Фиг там. Всё превратит в даты. И формат ячеек после вставки менять бесполезно - значения безвозвратно испорчены. Обязательно нужно отменить вставку, изменить формат и вставлять заново.
Ещё недоумение вызывает, что наши импортозамащатели могли бы исправить это и в чём-то стать лучше экселя, но они тупо скопировали этот бред (по крайней мере, насколько знаю).
Потому что бухгалтер Марьванна хочет ввести в ячейку A1 "12.2", в ячейку A2 - "13.4", в ячейку А3 - "=А2-А1" и посчитать, сколько там дней просрочки задолженности. А Марьванна из другой страны введёт "2/12" и "4/13". И обе Марьванны не будут выбирать формат ячейки - им сложно. Но если не получат желаемого, войдут в состояние фрустрации и задолбают до смерти своего эникейщика. А поскольку Марьванны в пользовательской базе Excel преобладают, то по дефолту вот так.
Единственное, что в этом можно поставить в вину MS - так то, что они не учитывают при преобразовании в дату локаль. Для Марьванны с русским языком нет смысла распознавать как дату "2/12". Но тут либо исторически сложилось (а как мы узнали из статьи, исторически сложиться могло вообще до появления Excel), либо вопрос переносимости файлов между разными локалями.
стала сильно не совпадать с весенним равноденствием
В оригинале "had fallen out of alignment with the Spring equinox". Дата Пасхи и не должна "совпадать" с весенним равноденствием. Пасха - это первое воскресенье после первого полнолуния после весеннего равноденствия, причём и равноденствие, и новолуние христиане получают расчётным путём (поэтому она может быть в разные дни у католиков и православных - алгоритмы одинаковы, но у православных старый стиль). Григорианский календарь был введён из-за "ухода Пасхи в лето", и фразу можно перевести "рассинхронизировалась с весенним равноденствием" или "слишком убежала от весеннего равноденствия".
Попробовал в Гугл Таблицах
="1/2"+1 получилось 45690
Видать оно кроссплатформено
Тот случай, когда для совместимости все должны ошибаться одинаково.
А что насчëт Libreoffice? Мне всегда казалось, что его поведение во многих аспектах адекватнее чем аналогов от MS. Но такие штуки как-то не попадались.
Это из за выбранной локализации. В американском виде 1/2 - это 2 января, в русской локализации это 1 февраля
А сильно давно раньше, был заветный флажок, который эту датнусть отключал по умолчанию...
До excel был знаком с supercalc. Классная вещь. Когда на своем первом конкурсе программирования была поставлена задача написать за 4 часа аналог электронной таблицы на apple basic смог что-то сделать представляя в уме supercalc.
Есть у меня сильное подозрение, что excel был не то, чтобы разработан в MS, а тупо слизан у Lotus. А причиной подозрения явилось то, что у Excel 5.0 справка была... именно от Lotus 1-2-3.
Проблема с типом содержимого и форматированием данных становится особенно актуальной при импорте данных из файлов Excel. Например, пользователь видит в ячейке число 1 и ожидает, что оно будет загружено как целое число. Однако представление в ячейке может быть различным:
Строковым: число отображается как текст.
Числовым: число отображается в числовом формате.
Датой с форматом отображения: число интерпретируется как дата, но отображается в определенном формате.
Формулой: число может быть результатом формулы, которая включает в себя предыдущие типы данных.
Есть еще более сложные случаи, когда необходимо извлечь проценты из ячейки. При форматировании в процентах внутри ячейки значение, рассчитанное по формуле: ПРОЦЕНТ = {ВВЕДЕННОЕ ЧИСЛО} / 100. Однако пользователи не всегда добавляют формат для ячейки и вводят проценты как число, поэтому необходимо дополнительно анализировать значение, чтобы определить, был ли это процент.
Ещё Excel очень было удобно использовать для перевода текстов игр. Сразу видно соответствие размеров текстов оригинала и перевода, колонка для ключей ресурсных ссылок, выделение цветом новых, проверенных, ошибочных текстов... Просто сказка!
Как в анекдоте - "Бл*, у тебя родной язык джаваскрипт что ли?"
Я не знаю, почему он выводит число вместо даты, но хотя бы понятно, как получилось это число.
Если знать, что в Эксель есть неявное преобразование типов, то вся магия пропадает.
Если Эксель встречает в формуле разные типы данных, то он пытается привести их к одному.
Давайте рассмотрим формулу ="1/2"+1 с учетом "тайного" знания о неявном преобразования типов. Что "видит" Эксель? Он видит математическую операцию (сложение), в которой с одной стороны строка с другой число.
Эксель будет пытаться преобразовать строку в число. "1/2" для Экселя - это дата и ничего кроме даты. Это не операция деления. Эксель не пытается вычислить что-то в кавычках. Для проверки можно ввести ="40/80"+1 .
почему он выводит число вместо даты
Потому что дата для экселя - это "число дней прошедшее с ...". Чтобы отображалась дата, надо сделать соответствующий формат ячейки.
Вот и вся магия.
Задача для самопроверки: =--"1/2" :)
Будьте прокляты производители холодильника. Положил колбасу, испортилась на следующий день.
Оказывается холодильник надо подключать к электроэнергии.
Ладно подключил холодильник в розетку, положил колбасу она испортилась на следующий день. Оказывается надо смотреть срок годности колбасы.
Посмотрел срок годности колбасы, холодильник подключен к розетки, но опять колбаса испортилась на следующий день. Оказывается нельзя держать после покупки, колбасу долго вне холодильника, надо сразу положить в холодильник после прихода домой.
Вот как я вижу эту статью.
Откройте мне тайну. Кому, зачем, и главное НАХЕРА нужно такое отображение чиcел?
1,21321E+45 ??? Ладно, если кому то прям нужно - то сделайте это отдельно включаемой опцией. Почему это дерьмо установлено по умолчанию, и я должен текстовый формат ячеек включать, чтобы видеть нормальное отображение чисел?
Ой, а как бы вы хотели видеть по умолчанию число, которое вы привели в пример? Вот так: 1213210000000000000000000000000000000000000000?
Так я хотя бы понимал бы, что вижу. Оно уже на 11 знаках схлопывается в этот бред. Например я работаю со штрихкодами, тот же EAN13 - база состоит из 12 знаков + сгенерированная контрольная цифра. Я привык работать с учсуд, но это идиотская функция. Что общего между читабельным 1234567891011 и 1,23457E+12?
1,21321E+45 - это не значит, что там 45 нулей.
Когда я вижу в какой-нибудь ячейке условного бюджета число 1,23457E+12, то я сразу понимаю, что это триллион рублей, а не сто миллиардов. 1234567891011 не читается вообще глазом, нужна как минимум отбивка 1 234 567 891 011, и та тоже читается хуже научной нотации. А уж когда вы даёте пример с сорока шестью цифрами...
EAN13 - не число, должно храниться как текст
В дополнение к комментарию про текст: у вас потеряются нули слева, если EAN будет вводиться как число. Если они когда-то будут...
наверно где то тут моя сегодняшняя проблема порылась, вывел в подписи графика года, в экселе норм, а в ворд скопировалось как 4**** , при чем даже в картинку так же вставилось (((
Excel, будь ты проклят: “1/2”+1=45660