Новости Embarcadero , Новости, патчи, ссылки, объявления, анонсы...

[P.O.D]

Delphi XE3
RAD Studio Mobile
HTML 5 Builder
Embarcadero MVP
Редакции Starter
Сертификация
AppWave

Холивары:
Есть ли будущее у Delphi?
Delphi vs C++ vs C# vs Java

Прошлые обсуждения:
Delphi XE2
Delphi XE
Delphi 2007
Delphi for PHP
Редакция Turbo
Delphi 2009
Delphi Prism
Delphi 2005
Новости CodeGear

Сообщение отредактировано: CodeMonkey - 06.02.13, 23:15

[leo]

Цитата Fr0sT @ 20.05.16, 15:50

а что есть "неверная дата"?

Из-за особенности представления дробной части TDateTime для отрицательных значений, недопустимыми являются значения между -1 и 0, и простые сложения\вычитания, при которых происходит переход через -1 или 0, приводят к неверному результату. Например, для значения 0.25 смещение на один день назад должно давать -1.25, а не -0.75

[Mr.Delphist]

Цитата Fr0sT @ 21.06.16, 08:07

Как все это соотносится с TDateTime?

Например, попробуйте вычесть N целых дней из сегодняшней даты так, чтобы попасть на "медведевский" интервал (когда было GMT+4) и сравните время (часы и минуты) обеих дат. Или хотя бы из любой даты "сразу после перехода на летнее время" вычесть пять минут. Т.е. с той наивной реализацией мы в любом случае получим какой-то TDateTime, но будет ли он правильным ответом? Конечно же, нет: ночные "3 часа 01 минута" минус "5 минут" в наивной реализации даст "2 часа 56 минут", а по факту это должно быть "1 час 56 минут" (т.к. переход на летнее время делался прыжком 2:00 -> 3:00, т.е. интервал 2:00 - 2:59 в ночь перевода стрелок просто не существует).

[leo]

Цитата Mr.Delphist @ 21.06.16, 20:45

Т.е. с той наивной реализацией мы в любом случае получим какой-то TDateTime, но будет ли он правильным ответом? Конечно же, нет: ...

С окольной реализацией через MSecs мы получим то же самое, т.к. функции типа IncDay и т.п., понятия не имеют какое время ты им подсовываешь - локальное или UTC. Поэтому для учета переходов с зимнего времени на летнее и обратно нужно самому конвертировать локальное времени в UTC и обратно методами класса TTimeZone (или по старинке через WinAPI).
Поэтому "у Delphi-команды дошли руки" только до того, чтобы исправить ошибку "наивной реализации" при переходе даты через полночь 30.12.1899 г. (смене знака TDateTime). Сделали они это дубово, зато универсально, т.к. эта корректировка нужна не только в IncDay, но и во всех IncXXX

[Fr0sT]

Mr.Delphist, вопрос с таймзонами особый, и к "голому" типу данных отношения не имеет. Корректная работа с ними должна включать постоянно обновляемую базу данных и явно выходит за рамки базового набора языка.
leo, спасибо за инфу. Зря они, конечно, пожидились на точку отсчета. С вместимостью Double можно было бы и от р.х. отсчитывать.

[leo]

Цитата Fr0sT @ 22.06.16, 08:10

Зря они, конечно, пожидились на точку отсчета. С вместимостью Double можно было бы и от р.х. отсчитывать.

Точка отсчета не имела бы значения, если бы TDateTime представлялась бы линейно\единообразно на всей оси, а не зеркально для отрицательных значений. Для этого DateOf(dt) должна определяться не как Int\Trunc, а как Floor(dt), а TimeOf(dt) всегда д.б. положительным и определяться не через Frac(dt), а через dt-Floor(dt). Иначе для отрицательных dt и TimeOf(dt) получается отрицательным (?!). Какой в этом смысл, не понятно...

Добавлено 23.06.16, 04:37
PS: Кстати, зеркальное представление TimeOf приводит к тому, что "наивные реализации" IncHour и ниже дают неверный результат не только при переходе через 0 (как IncDay и выше), но и для любых отрицательных значений - смещение происходит в противоположную сторону...

[Fr0sT]

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

Добавлено 23.06.16, 06:44
А проблемы с отрицательными значениями будут у любого линейного представления, хоть в мсек от н.э., хоть в наносек от сотворения мира. Разве что структура типа SYSTEMTIME спасет, но она уж больно неудобна для арифметики и хранения.

[leo]

Цитата Fr0sT @ 23.06.16, 06:42

А проблемы с отрицательными значениями будут у любого линейного представления

С какой стати? Если бы dt:=0.25 при смещении на 1 сутки назад представлялась бы "обычно", как 0.25-1 = -0.75 (Date = -1, Time = +0.25), а не -1.25 ((Date = -1, Time = -0.25), то какие тут были бы проблемы? В использовании Floor вместо Trunc?

[Fr0sT]

Цитата leo @ 23.06.16, 07:53

какие тут были бы проблемы?

При таком алгоритме да, вроде бы все нормально. Но почему-то решили делать ужасающие каскады преобразований вместо легких доработок. И самый прикол в том, что удобство типа (разделение даты и времени, автоматический переход целых суток в дату из времени при наращивании) получается полностью нивелировано. В чем тогда цимес продолжать использовать Double, имея неочевидные траблы со сравнением, например?

[leo]

Цитата Fr0sT @ 22.06.16, 08:10

Зря они, конечно, пожидились на точку отсчета. С вместимостью Double можно было бы и от р.х. отсчитывать.

Цитата Fr0sT @ 23.06.16, 11:06

В чем тогда цимес продолжать использовать Double, имея неочевидные траблы со сравнением, например?

В совместимости с MS OLE. В Delphi 1 был тот же double с отсчетом от р.х., а в 32-битной D2 TDateTime сделали совместимым с OLE Variant DATE. Точку отсчета сместили, а с дурной зеркальностью отрицательных значений слегка прокололись - в функциях конвертации даты ее учли, а в IncXXX, видимо, забыли или забили

Добавлено 24.06.16, 06:20
Ха, оказывается в D7 и EncodeDateTime работает не правильно - без учета зеркальности отрицательных значений. Для 29.12.1899 6:00 выдает -0.75 вместо -1.25

[Fr0sT]

Цитата leo @ 24.06.16, 05:57

В совместимости с MS OLE

И тут МС подгадил

[leo]

Цитата Fr0sT @ 24.06.16, 11:53

И тут МС подгадил

Судя по байкам, МС сам в свое время "влип" с этим форматом представления даты, переняв его от Lotus 1-2-3, для обеспечения совместимости с Excel. Говорят, что первое время в Excel воспроизводилась ошибка Lotus в представлении 1900 г., как високосного (хотя по Григорианскому стилю он таковым не является). Потом для исправления этой ошибки пришлось сместить начало отсчета даты на 1 день назад (отсюда и не круглая цифра - декабрь 1899 г., но почему в итоге разница стала составлять 2 дня, а не 1, история умалчивает). Ну а с Lotus-а взятки гладки - в стародавние досовские времена было не до нынешнего жиру, поэтому и на 100 и 400 летние поправки к високосности попросту забили, и для зеркального представления отрицательных значений времени видимо имелись какие-то причины, связанные с реализацией.

[leo]

Цитата Fr0sT @ 23.06.16, 11:06

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

Согласен. Раз уж не только IncXXX, но и EncodeDateTime не учитывала особенности представления OLE DATE для отрицательных значений, то можно было бы оставить все как есть (с линейным представлением DateTime на всей оси), а для совместимости с OLE добавить новый тип TOleDateTime и поправить функции VarToDateTime и VarFromDateTime.

[s2004]

Помогите советом я вполне возможно не в той теме, среда программирования нормально работала, примерно 10 месяцев не пользовался и вот тебе при компиляции пользуюсь кнопками cntrl+f9, chift+f9, а они перестали работать, полазил по менюшкам поставил по дефолту, но ничего не работает, кроме этого очень неудобно, где настройки проверить в справке не увидел.

Сообщение отредактировано: s2004 - 11.02.17, 20:23

[Krid]

Tools->Options->Editor Options->Editor SpeedSetting->Default keymapping

[s2004]

Editor SpeedSetting этого нет
->Default keymapping это стояло, но пока не работает.