Некорректный экспорт времени в XLSX

[Fait]

Если посмотреть внимательно скрин топикстартера - там значение ячейки не 8:00, а ШТРИХ8:00. Тут проблема не в программе Руко!

Да, именно!
Апостроф ставится там, где значение должно остаться текстом.
Например, при импорте номеров телефонов, начинающихся с +7 будет точно такой же апостроф в начале.
А если его убрать, то эксель выдаст ошибку

[HetmanNet]

Но я пока не пойму из за чего такой глуюк. Тип ячейки вроде как общий.

Возможно именно из-за этого?

Так понял есть несколько причин:
1. библиотека (да понимаю это phpspreadsheet) используемая для экспорта при отсутствии указанного типа экспортирует все как текстовые данные (в структуре файла xlsx они хранятся отдельно в xl/sharedStrings.xml от остальных типов в xl/wokrsheets/sheet1.xml).
2. не каждая программа автоматически преобразует типы данных из текста, соответственно пока не кликнешь по нужной ячейке (не войдешь в режим редактирования) преобразования нет, ибо подобное приходится делать в некоторых версиях с датами, чтобы их начало воспринимать как дату.

Думаю использование при экспорте данных типов данных устранило эти проявления: то есть числа как числовые типы, даты как даты, время как время, и т.п.

Кликнуть по сотням ячеек как-то не очень удобно, но не каждый пользователь догадывается.

[nruslan2]

в самом экселе установите в ячейке нужный тип данных и все будет великолепно работать

зы и для телефона тоже)) и никаких доп опострафов ненадо)

[HetmanNet]

в самом экселе установите в ячейке нужный тип данных и все будет великолепно работать

не работает, поэтому эту тему создал

[support]

библиотека (да понимаю это phpspreadsheet) используемая для экспорта при отсутствии указанного типа экспортирует все как текстовые данные.

Все верно. И в текстовых данных недолжно ничего добавляться в начале. Программа сама ничего не добавляет.

[HetmanNet]

библиотека (да понимаю это phpspreadsheet) используемая для экспорта при отсутствии указанного типа экспортирует все как текстовые данные.

Все верно. И в текстовых данных недолжно ничего добавляться в начале. Программа сама ничего не добавляет.

Именно в этом проблема, потому что все данные экспортируются как текст независимо от типа поэтому программа по умолчанию с ними обязана вести себя как текст. Нигде не определено, что программа должна проверять текстовые данные на предмет возможности приведения к другому типу. Что кстати и видим в разном поведении в зависимости от разработчика и версии.
Также спецификация на формат файла дала подсказку, потому что в ней четко заметно, как разработчики разделяют все типы данных на две категории: текстовые и числовые. Что может объяснить, почему возникают проблемы с автоматическим приведением одного типа к другому, или появление защиты типа (тот символ, который вставляет программа при отображении, но не хранит в файле). Сохраняя числовые типы как текст нарушаете спецификацию на формат файла и соответственно не можете ожидать прогнозируемого поведения в данной ситуации.

[support]

1) Данные экспортируются, как они выводятся, тоесть в своем формает. Число может иметь префикс/суфикс + свой формат. Пример: 1 000 000 руб.
Я не могу для таких данных установить числовой тип ячейки. Данные будут не корректно отображаться.

2) Для текстового формата excel не должен ничего добавлять. Это какой то глюк в самом excel.

[HetmanNet]

1) Данные экспортируются, как они выводятся, тоесть в своем формает. Число может иметь префикс/суфикс + свой формат. Пример: 1 000 000 руб.
Я не могу для таких данных установить числовой тип ячейки. Данные будут не корректно отображаться.

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

Но дело в том, что проблема с системными типами, то есть типами формат которых известен и можно определить автоматически.

2) Для текстового формата excel не должен ничего добавлять. Это какой то глюк в самом excel.

Это не глюк ms exel или другого табличного процессора, выяснилось, он таким образом маркирует ячейки, которые без данной маркировки пользователем могут быть восприняты некорректно, т.е. не данные в сохраненном файле добавили такую метку (она в файлы не сохраняется, только отображается).

Но независимо маркирует программа данные данные или нет, она с ними не работает как с числами и считает просто текстом пока в процессе редактирования значение не выполняет преобразование, потому что именно такая определенная трактовка предусмотрена форматом файла.

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

Так что хотите или нет, но авторы формата не предусмотрели альтернативный сценарий для корректного хранения данных, поэтому для предполагаемой работы нужно корректно задавать типы в файле.

Отсутствие возможности экспортировать корректно данные для расчетов лишают весомой доли возможностей.

[support]

Добавил в план возможность задать тип колонки при экспорте.