Здравствуйте, vopl, Вы писали:

V>Всё, вопрос закрыт. Этот код решает проблемы с временим на ближайшие 200 миллиардов лет, с точностью до наносекунд.
V>Всё, вопрос закрыт. Этот код решает проблемы потому что тоже самое, да еще и практический диапазон (9999AD до 9999BC).
V>
Я понял. Вы из этого комитета.

Ну что же, сочуствую. Сложно жить без моска.

Здравствуйте, Cyberax, Вы писали:

C>Всё, вопрос закрыт. Этот код решает проблемы с временим на ближайшие 200 миллиардов лет, с точностью до наносекунд.
Не хочу с точностью до наносекунд.
Хочу с точностью до 1/60-й секунды.
Т.е. квант должен быть ровно 1/60-я.
Ну или там 1/37-я.

Здравствуйте, Cyberax, Вы писали:

C>Всё, вопрос закрыт. Этот код решает проблемы с временим на ближайшие 200 миллиардов лет, с точностью до наносекунд.

А мне, к примеру, нужно представление времени с показателем качества часов (тут в соседней теме про IEC61850 спрашивали, там такое есть)

Здравствуйте, 3V, Вы писали:

C>>Всё, вопрос закрыт. Этот код решает проблемы с временим на ближайшие 200 миллиардов лет, с точностью до наносекунд.
3V>Не хочу с точностью до наносекунд.
3V>Хочу с точностью до 1/60-й секунды.
Кстати, это называется "терция".

3V>Т.е. квант должен быть ровно 1/60-я.
3V>Ну или там 1/37-я.
Ну пиши тогда свой класс и не занимайся сексом с мозгами других людей. Один фиг, или придётся писать все функции форматированного вывода с нуля, или преобразовывать в десятичные.

Здравствуйте, landerhigh, Вы писали:

C>>Всё, вопрос закрыт. Этот код решает проблемы с временим на ближайшие 200 миллиардов лет, с точностью до наносекунд.
L>А мне, к примеру, нужно представление времени с показателем качества часов (тут в соседней теме про IEC61850 спрашивали, там такое есть)

struct time_with_quality_t {
   timestamp_t time_;
   quality_t quality_;
};

И всё.

Здравствуйте, Cyberax, Вы писали:

3V>>Т.е. квант должен быть ровно 1/60-я.
3V>>Ну или там 1/37-я.
C>Ну пиши тогда свой класс и не занимайся сексом с мозгами других людей. Один фиг, или придётся писать все функции форматированного вывода с нуля, или преобразовывать в десятичные.

В С++20 добавленно форматирование, в том числе и для std::chrono. С fmtlib это можно использовать чуть ли ни в C++11: https://godbolt.org/z/1WKoG8

#include <chrono>

#include <fmt/core.h>
#include <fmt/chrono.h>

int main()
{
    using namespace std::literals::chrono_literals;

    using deciseconds = std::chrono::duration<int64_t, std::ratio<1, 10>>;
    using tertia = std::chrono::duration<int64_t, std::ratio<1, 60>>;

    fmt::print("Custom duration: {}\n", std::chrono::seconds{1} + deciseconds{1} + tertia{3});
    fmt::print("Standard durations: {} {} {} {}\n", 1h, 5min, 6s, 10ns );
}

Program returned: 0
Program stdout
Custom duration: 69[1/60]s
Standard durations: 1h 5m 6s 10ns

Здравствуйте, Cyberax, Вы писали:

L>>А мне, к примеру, нужно представление времени с показателем качества часов (тут в соседней теме про IEC61850 спрашивали, там такое есть)
C>

C>struct time_with_quality_t {
C>   timestamp_t time_;
C>   quality_t quality_;
C>};
C>

C>И всё.

Да вот не все. Там есть особенности.
Короче, попаболь понятна, но стандартом покрыть все потребности в любом случае не выйдет.

Здравствуйте, PM, Вы писали:

C>>Ну пиши тогда свой класс и не занимайся сексом с мозгами других людей. Один фиг, или придётся писать все функции форматированного вывода с нуля, или преобразовывать в десятичные.
PM>В С++20 добавленно форматирование, в том числе и для std::chrono. С fmtlib это можно использовать чуть ли ни в C++11: https://godbolt.org/z/1WKoG8
Ну я очень рад за терции и тем 10 людям в мире, которым они потребуются. Но какой чёрт до сих пор нет форматирования для миллисекунд в put_time?

Здравствуйте, landerhigh, Вы писали:

L>Короче, попаболь понятна, но стандартом покрыть все потребности в любом случае не выйдет.

Задача любого стандарта заключается в том, чтобы (на сколько возможно) покрыть потребности "99% пользователей", Java/C# с этим прилично справляются с мохнатых времен, во всяком случае, разработчики не тратят время на обсуждение подобных вещей, а если нужен тот самый уникальный "1%" — велосипедьте себе на здоровье, никто не мешает.

Здравствуйте, Cyberax, Вы писали:

C>Я уже молчу об отдельном квесте: "напечатай мне время в ISO с наносекундами". Почему-то в комитете не подумали, что это кому-то может быть нужно.

C>Дубинкой бы их всех там надо пару раз по голове стукнуть.

В стандарте с недостатком концептов тоже беда, но ничего, кушаем, что дают
В чём проблема взять готовое решение в интернете:

#include <iostream>
#include <string>

using namespace std;

template <class Precision>
string getISOCurrentTimestamp()
{
    auto now = chrono::system_clock::now();
    return date::format("%FT%TZ", date::floor<Precision>(now));
}

int main() {

 cout << getISOCurrentTimestamp<chrono::nanoseconds>();   
}

2020-12-29T20:45:46.149347442Z

Здравствуйте, 4058, Вы писали:

4>Задача любого стандарта заключается в том, чтобы (на сколько возможно) покрыть потребности "99% пользователей", Java/C# с этим прилично справляются с мохнатых времен,

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

4>во всяком случае, разработчики не тратят время на обсуждение подобных вещей, а если нужен тот самый уникальный "1%" — велосипедьте себе на здоровье, никто не мешает.

Везде есть свои погремушки. Для Java есть костыли типа Azul, которые решают проблемы, которой в плюсах просто нет.

Здравствуйте, landerhigh, Вы писали:

4>>Задача любого стандарта заключается в том, чтобы (на сколько возможно) покрыть потребности "99% пользователей", Java/C# с этим прилично справляются с мохнатых времен,

Да ладно! Цифра 99% как раз и говорит о том что эти мифические продвинутые возможности нафиг никому не впарились. Надо было просто сделать нормально, а тот 1% пусть сам себе велосипедит что хочет.

GC: кроме того на какой форум не заглянь — везде про chrono куча вопросов (элементарных/житейских) — это явный признак плохой библиотеки.

Здравствуйте, AeroSun, Вы писали:

AS>GC: кроме того на какой форум не заглянь — везде про chrono куча вопросов (элементарных/житейских) — это явный признак плохой библиотеки.

Старческое брюзжание

Здравствуйте, _NN_, Вы писали:

C>>Дубинкой бы их всех там надо пару раз по голове стукнуть.
_NN>В стандарте с недостатком концептов тоже беда, но ничего, кушаем, что дают
_NN>В чём проблема взять готовое решение в интернете:
Потому, что это БЛДЖАД, около 10000 строк дополнительного кода. С непонятной поддержкой ("Дядя Вася Inc.") и гарантиями по безопасности. Если этот "Дядя Вася Inc." завтра забросит эту библиотеку, то придётся вникать в эти 10 тысяч строк весьма нетривиального кода.

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

Здравствуйте, landerhigh, Вы писали:

4>>Задача любого стандарта заключается в том, чтобы (на сколько возможно) покрыть потребности "99% пользователей", Java/C# с этим прилично справляются с мохнатых времен,
L>Это в свою очередь может говорить об ограниченности потребностей 99% пользователей данных языков.
Любая инженерная задача — это поиск компромисов. Вариант: "сделать жизнь сложной для 100% пользователей, чтобы 0.1% пользователей, в теории, могли бы использовать стандартные классы", — очень плохой.

О потребностях. У меня код как раз занимается прикладной астрономией. Так что перевод отметок времени в юлианские дни — это обычная фича. Более того, у нас даже есть код, который пересчитывает время в самые настоящие марсианские дни ("солы"?).

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

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, _NN_, Вы писали:

C>>>Дубинкой бы их всех там надо пару раз по голове стукнуть.
_NN>>В стандарте с недостатком концептов тоже беда, но ничего, кушаем, что дают
_NN>>В чём проблема взять готовое решение в интернете:
C>Потому, что это БЛДЖАД, около 10000 строк дополнительного кода. С непонятной поддержкой ("Дядя Вася Inc.") и гарантиями по безопасности. Если этот "Дядя Вася Inc." завтра забросит эту библиотеку, то придётся вникать в эти 10 тысяч строк весьма нетривиального кода.
У всего есть достоинства и недостатки.
Я бы не сказал, что стандартная библиотека эталон качества кода.
Количество банальнейших багов там не так мало.

C>Ради форматирования, которое в других языках есть в стандартной библиотеке (поддерживаемой авторами языка).
Это другое дело.
Осталось предложение в стандарт внести.

Здравствуйте, Cyberax, Вы писали:

C>>>Вот так выглядит печать времени с наносекундами в Go:
V>>Не надо вилять. 200 миллиардов лет есть? Нет. Выписываем ненависть. А тебе — кубок вилятора.
C>Фича в том, что для Go взамен 200 миллиардов лет есть очень красивый API. Это вполне себе неплохой инженерный компромис.

C>В C# — аналогичная история. Только они пожертвовали точностью для того, чтобы уметь представлять даты из практического диапазона (9999AD до 9999BC).

В C# вообще особо не думали, они применили 1:1 подход и точность часов Windows NT (64 бита и 100 нс), только сместили точку отсчёта и добавили знак. С другой стороны, у них были причины полагать, что подход NT практически пригоден "в целом по больнице".

C>Но в С++ комитет абсолютно и непреклонно бескомпромисный. Так что они пожертвовали ВСЕМ одновременно. Так что в С++ нет ни красивого API, ни интервала в миллиарды лет.

Я вот таки не понимаю, чем тебе, например, 1 мкс недостаточно, а 100 нс — достаточно. Что за задача такая?
64 бита в микросекундах — вполне достижимо на chrono стандартными средствами и даёт 290 000 лет со знаком.

Здравствуйте, Cyberax, Вы писали:

V>>Всё, вопрос закрыт. Этот код решает проблемы с временим на ближайшие 200 миллиардов лет, с точностью до наносекунд.
V>>Всё, вопрос закрыт. Этот код решает проблемы потому что тоже самое, да еще и практический диапазон (9999AD до 9999BC).
V>>
C>Я понял. Вы из этого комитета.

C>Ну что же, сочуствую. Сложно жить без моска.

Смешались в кучу кони, люди...

У тебя в этом треде три совершенно разных вопроса:
1) Виртуальный метод для часов.
2) Стандартные функции печати времени в чём-то удобном типа ISO8601 с долями секунд.
3) Тип данного хранения времени, чтобы иметь и диапазон, и точность.

(1) — по-моему, никто не понял. что ты вообще хотел.

(2) — согласен.

(3) — ты таки заслужил "орден вилятора" ([vopl@]), когда согласился с тем, что в Go "красивый API" и это тебе перевешивает недостатки (хотя если у тебя действительно были бы проблемы диапазона и/или точности — тебе бы никакой API не помог).

Со своей стороны хотел бы заметить, что я слабо представляю себе цели и времени шире плюс-минус 100 лет в обе стороны, и точности дальше микросекунд. Если это где-то есть, то это спецзадача, для которой нет ресурсных проблем потратиться на реализацию на структуре, которую ты предлагал, или на int128_t (даже самопальном). Но скорее всего такое не нужно.
Жду комментария, почему тебе 1 мкс недостаточно. а 100 нс достаточно.

По поводу печати долей секунды — реально это забывают в до чёрта мест. Я вот с офигением смотрю на наши хаки поверх log4cplus для этого же (интересно, в более новой версии починены? обновляться мы пока не осиливаем).

Здравствуйте, netch80, Вы писали:

C>>В C# — аналогичная история. Только они пожертвовали точностью для того, чтобы уметь представлять даты из практического диапазона (9999AD до 9999BC).
N>В C# вообще особо не думали, они применили 1:1 подход и точность часов Windows NT (64 бита и 100 нс), только сместили точку отсчёта и добавили знак. С другой стороны, у них были причины полагать, что подход NT практически пригоден "в целом по больнице".
Время в NT было сделано так, чтобы представлять все четырёхзначные даты (64 бит по 100 нс имеют диапазон значений в 50 тысяч лет) с достаточной точностью. В принципе, они могли бы сделать квант в 50 нс, но это уже мелочь.

C>>Но в С++ комитет абсолютно и непреклонно бескомпромисный. Так что они пожертвовали ВСЕМ одновременно. Так что в С++ нет ни красивого API, ни интервала в миллиарды лет.
N>Я вот таки не понимаю, чем тебе, например, 1 мкс недостаточно, а 100 нс — достаточно. Что за задача такая?
100нс мне недостаточно, но я считаю решение в C# неплохим компромисом.

Здравствуйте, netch80, Вы писали:

C>>Ну что же, сочуствую. Сложно жить без моска.
N>Смешались в кучу кони, люди...
N>У тебя в этом треде три совершенно разных вопроса:
N>1) Виртуальный метод для часов.
Да.

N>2) Стандартные функции печати времени в чём-то удобном типа ISO8601 с долями секунд.
Да.

N>3) Тип данного хранения времени, чтобы иметь и диапазон, и точность.
Да.

N>(1) — по-моему, никто не понял. что ты вообще хотел.
Простейшая вещь — возможность заменять часы в тестах.

N>Со своей стороны хотел бы заметить, что я слабо представляю себе цели и времени шире плюс-минус 100 лет в обе стороны, и точности дальше микросекунд.
Задача простая — есть электронная таблица, где есть тип "отметка времени". Туда пользователи могут добавлять любые даты из разумного диапазона. Это могут быть как исторические даты (скажем, даты начала и конца войн), так и данные с наносекундной точностью (скажем, результаты профилирования кода). Для всех дат надо поддерживать арифметику, стандартные операции и т.п.

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