|
Notes |
|
|
(0004733)
|
|
Tolik
|
|
29-12-2011 18:47
|
|
|
И у меня на старой винде то же самое. |
|
|
|
(0004739)
|
|
DJ VK
|
|
30-12-2011 04:40
|
|
проблема в том, что это время соответствующее географическому часовому поясу.
Тогда уж должна быть в 2 часа разница. У нас еще в 1930 году ЕРЖ сделали не как у всех. А в 2011 еще более мастистые ЕРЖ добавили еще 1 час опережения.
Вычисление времени вот такое сейчас.
function TLayerStatBar.GetTimeInLonLat(ALonLat: TDoublePoint): TDateTime;
var
tz: TDateTime;
st: TSystemTime;
begin
tz := FTimeZoneDiff.GetTimeDiff(ALonLat);
GetSystemTime(st);
Result := EncodeTime(st.wHour, st.wMinute, st.wSecond, st.wMilliseconds);
Result := Result + tz;
Result := Frac(Result);
end; |
|
|
|
(0004742)
|
|
Tolik
|
|
30-12-2011 05:29
|
|
Добавлю: и на новой пропатченной винде тоже неправильно показыввает. В Москве.
Ну а эта функция FTimeZoneDiff.GetTimeDiff() откуда берёт разницу во времени? Из какой-то таблицы? Типа, tzdata2011k.tar.gz? |
|
|
|
(0004743)
|
|
DJ VK
|
30-12-2011 09:46
(edited on: 30-12-2011 09:49) |
|
Да если бы.
unit u_TimeZoneDiffByLonLatStuped; - то есть примитивное вычисление
constructor TTimeZoneArea.Create(ASmallIntPolygon: Pointer; ALength: Integer);
var
i: Integer;
begin
FCount := ALength;
SetLength(FPolygon, FCount);
for i := 0 to FCount - 1 do begin
FPolygon[i].X := SmallInt(Pointer(Integer(ASmallIntPolygon)+SizeOf(SmallInt)*2*i+SizeOf(SmallInt)*0)^)/100;
FPolygon[i].Y := SmallInt(Pointer(Integer(ASmallIntPolygon)+SizeOf(SmallInt)*2*i+SizeOf(SmallInt)*1)^)/100;
end;
end;
.....
VAreaList := TInterfaceList.Create;
VArea := TTimeZoneArea.Create(@timezone_3, length(timezone_3));
VAreaList.Add(VArea);
VArea := TTimeZoneArea.Create(@timezone_3_1, length(timezone_3_1));
VAreaList.Add(VArea);
VZone := TTimeZone.Create(3, VAreaList);
FTimeZoneList.Add(VZone);
'timezone_3' = '(UTC +3:00) Moscow, Baghdad, Khartoum, Saint Petersburg';
unit c_TimeZones;
timezone_3:array [0..729,0..1]of smallint = (
(4279,3738),(4296,3732),(4315,3738),(4328,3732),(4336,3733),(4349,3725),(4379,3723),(4383,3720),(4391,3722),(4401,3732),(4412,3732),(4426,3724),(4427,3717),(4419,3710),(4426,3699),(4432,3697),(4435,3705),(4444,3706),(4464,3719),(4479,3715)...............
значит надо править таблицу 3й зоны и 4й.
придется попотеть, если кто не скачает новую
|
|
|
|
(0005028)
|
|
Tolik
|
17-01-2012 06:20
(edited on: 17-01-2012 06:22) |
|
Из бага 1118 (by bk99):
В строке статуса отображается локальное время на территории, находящейся под курсором мыши. Известно, что Омск и Новосибирск находятся в одном часовом поясе (+3 часа с Москвой). В Планете же отображается разница с Москвой для Омска +3 часа (это верно), а для Новосибирска +4 часа (это ошибка).
И ещё пожелание. В статусной строке отображать время в формате: "14:45:00(+6GMT)" (сейчас отображается просто: "14:45:00"). Или ещё проще: "14:45(+6GMT)" - без секунд.
|
|
|
|
(0005031)
|
|
Tolik
|
17-01-2012 06:38
(edited on: 17-01-2012 07:12) |
|
Здесь есть 100320.kmz с координатами часовых поясов, но устаревший: http://bbs.keyhole.com/ubb/ubbthreads.php?ubb=showflat&Number=228782#Post228782
Если нет лучшего, я думаю, легче исправить устаревший, чем создавать новый.
А из него уж как-то и в код сконвертировать...
Здесь TimeZones.kmz, практически то же самое:
http://www.midlothian-isd.net/~tech_training/FOV1-00026E80/FOV1-0002F09D/FOV1-0002F0AD/
|
|
|
|
(0005712)
|
|
Tolik
|
|
28-02-2012 13:55
|
|
Скажите, а в каких единицах координаты точек в unit c_TimeZones?
Может кто-нибудь эти безумные массивы сконвертировать в формат kml и обратно?
Я мог бы тогда мог эти полигоны загрузить и исправить.
А вообще надо предусмотреть возможность редактировать их регулярно: таймзоны меняются по несколько раз в год. |
|
|
|
|
>Скажите, а в каких единицах координаты точек в unit c_TimeZones?
Это градусы умноженные на 100
>Может кто-нибудь эти безумные массивы сконвертировать в формат kml и обратно?
Может кто-то и может, но скорее всего готовых инструментов нет.
> вообще надо предусмотреть возможность редактировать их регулярно
Ваши предложения? |
|
|
|
(0005714)
|
|
Tolik
|
|
28-02-2012 14:35
|
|
Предложение - написать скрипт, который эти массивы преобразует в kml и обратно.
Либо переписать программу так, чтобы она брала данные прямо из kml, но это труднее.
Инструмент, наверно, был, ведь кто-то не ручками вбивал эти цифры? |
|
|
|
(0005715)
|
|
Tolik
|
28-02-2012 15:00
(edited on: 28-02-2012 15:02) |
|
Я с помощью ворда и экселя сделал из "timezone_3:array [0..729,0..1]of smallint" файл 3.csv, запихнул в GPSBabel и получился 3.kml.
Он полностью совпадает с одним из кусков TimeZones.kmz (несколькими постами выше)!
Надо автоматизировать этот процесс, а главное, обратный (из kml в array).
Да, и ещё надо придумать, как редактировать kml :)
|
|
|
|
(0005716)
|
|
zed
|
|
28-02-2012 15:58
|
|
Нарыл интересный компонентик: http://code.google.com/p/delphi-tzdb/ берёт последние официальные данные по временным зонам (http://www.iana.org/time-zones).
Только, насколько я понял, там нет границ как таковых, а просто указаны страны/штаты/регионы и их временные зоны (причём, данные есть начиная чуть ли не с позапрошлого века). Т.е. в программе нужно хранить полигоны границ стран (которые меняются на порядок реже временных зон), по этим границам и координатам курсора вычислять название страны/региона, по которым и определять время и часовой пояс. А может там всё ещё проще и никакие границы хранить не нужно? |
|
|
|
|
|
Нет. Нужно где-то брать границы. В tzdb хранятся только названия зоны и инфа когда она действовала, разница во времени и есть ли переход на летнее время. |
|
|
|
(0005719)
|
|
zed
|
28-02-2012 16:29
(edited on: 28-02-2012 17:09) |
|
А вот и готовые границы: http://efele.net/maps/tz/
Только размер этих границ на порядок больше, чем сейчас в САСе. А если перегнать их в kml, так вообще 80 МБ выходит.
|
|
|
|
(0005720)
|
|
Tolik
|
|
28-02-2012 17:20
|
|
> нужно хранить полигоны границ стран
Только в некоторых странах несколько таймзон. И в одной из них они постоянно меняются... |
|
|
|
(0005721)
|
|
Tolik
|
|
28-02-2012 17:25
|
|
> А если перегнать их в kml, так вообще 80 МБ выходит.
А как перегнать shape в kml?
Приаттачьте kml, пожалуйста.
Раз он такой большой, можно выкинуть половину (или 9/10) точек. |
|
|
|
(0005722)
|
|
zed
|
|
28-02-2012 17:44
|
|
Перегоняется утилиткой shp2kml: http://www.zonums.com/shp2kml.html
KML тут: http://www.mediafire.com/?qxxdqpq48ov85u6
В принципе, сам shp файл хорошо сжимается (до 8Мб), плюс можно сконвертировать его в свой бинарный формат (типа *.stz - sas time zone), после что думаю, раза в 2 оно должно стать ещё компактнее. Но всё равно, размер будет соизмерим с размером релиза самого САС, что думаю, может стать принципиальным препятствием. |
|
|
|
(0005723)
|
|
Tolik
|
28-02-2012 17:58
(edited on: 28-02-2012 17:59) |
|
Спасибо.
В этом kml слишком много объектов: каждая страна выделена, их бы объединить - нет ли готового инструмента для этого?
Тогда очень много точек - границы стран в пределах одной таймзоны - будет удалено.
|
|
|
|
(0005724)
|
|
zed
|
|
28-02-2012 18:06
|
|
|
Их нельзя объединять. Каждому полигону соответствует свой TZID, зная который можно получить таймзону из tzdb. |
|
|
|
(0005725)
|
|
Tolik
|
|
28-02-2012 18:11
|
|
Да, это было бы неплохо. И обновлять легко. Но слишком много точек - будет тормозить. Ну, тогда можно просто выкинуть часть точек. Какое число точек (или размер kml) ещё приемлемо?
Может написать сначала код для этого готового kml, посмотреть, насколько тормозит, а потом уж упрощать? |
|
|
|
(0005726)
|
|
zed
|
|
28-02-2012 18:16
|
|
Вопрос скорее не в том, будет тормозить или нет (в этом плане можно придумать какие-нибудь оптимизации), а в собственно размере этих данных.
Да и выбрасывать что-то вручную - неблагодарное дело.
|
|
|
|
(0005727)
|
|
Tolik
|
|
28-02-2012 18:20
|
|
|
При конвертации в тот формат, что сейчас (целые числа = градусы*100) уже сократится раза в 4. |
|
|
|
(0005728)
|
|
Tolik
|
28-02-2012 18:32
(edited on: 28-02-2012 18:34) |
|
У этого файла ещё 1 недостаток: охвачена только суша, в морях никаких полигонов нет.
> Да и выбрасывать что-то вручную - неблагодарное дело.
Можно и не вручную: оставить каждую 3-ю (5-ю, 10-ю) точку, остальные отбросить.
|
|
|
|
(0005729)
|
|
zed
|
|
28-02-2012 19:02
|
|
Timezones at sea
The tz database says: “A ship within the territorial waters of any nation uses that nation's time. In international waters, time zone boundaries are meridians 15° apart, except that UTC−12 and UTC+12 are each 7.5° wide and are separated by the 180° meridian (not by the International Date Line, which is for land and territorial waters only). A captain can change ship's clocks any time after entering a new time zone; midnight changes are common.”
While the boundaries in international waters are not difficult to construct, the boundaries of territorial waters are a completely different story, and are similar to the boundaries between countries. Unfortunately, VMAP0 does not provide geometries for the territorial waters. As a consequence, the shapefiles presented here do not cover seas and oceans. |
|
|
|
(0005730)
|
|
zed
|
|
28-02-2012 19:36
|
|
>При конвертации в тот формат, что сейчас (целые числа = градусы*100) уже сократится раза в 4.
Что ж, попробую написать конвертер из kml в бинарный формат, посмотрим насколько компактным оно получится. |
|
|
|
|
>размер будет соизмерим с размером релиза самого САС, что думаю, может стать принципиальным препятствием
А почему бы вообще не выкинуть это из релиза и не сделать как дополнительную опцию? Кому надо - качнёт, включит и будет наслаждаться таймзонами. Безо всяких конвертаций, в оригинальном формате. Обновились зоны - слили новую инфу - и дальше всё работает прямо сейчас и без перезапуска и обновления саса. Лично мне вообще не надо локальное время под мышкой на основе текущего времени на компе, например, при навигации. Да и по жизни требовалось пару раз всего, и то больше как просто _смещение_ узнать, а не само по себе время. |
|
|
|
(0005752)
|
|
Tolik
|
|
29-02-2012 12:54
|
|
Часто смотрю время в других городах на timeanddate.com, этого достаточно. Но если САС будет показывать _достоверную_ инфу - тоже буду пользоваться.
Хорошо бы просто положить в директорию САС tzdata2011k.tar.gz и брать инфу оттуда. |
|
|
|
(0005772)
|
|
zed
|
|
01-03-2012 17:20
|
|
>А почему бы вообще не выкинуть это из релиза и не сделать как дополнительную опцию?
Тоже об этом думал.
>Хорошо бы просто положить в директорию САС tzdata2011k.tar.gz и брать инфу оттуда.
Ну, это с точки зрения пользователя - хорошо. На самом деле - не очень. Если положить файл tzdb и файл с границами, то ведь их же придётся при _каждом_ запуске САСа парсить и переводить во внутреннее представление, чтобы можно было с этими данными как-то работать. А это, знаете-ли, не шибко быстрая операция. Поэтому, лучше эти данные всё-таки подготовить заранее. |
|
|
|
(0006670)
|
|
zed
|
|
04-05-2012 19:49
|
|
Интересный топик, по схожей проблеме http://habrahabr.ru/post/143277/
А ещё более меня заинтересовал комментарий, что всё описанное можно легко и эффективно сделать при помощи функций СУБД (среди прочих упомянута и SQLite).
Непродолжительное гугление вывело меня на библиотеку SpatiaLite https://www.gaia-gis.it/fossil/libspatialite/home
SpatiaLite is an open source library intended to extend the SQLite core to support fully fledged Spatial SQL capabilities.
SQLite is intrinsically simple and lightweight
Т.е. насколько я понял, можно:
- автоматически сконвертировать *.shp файл с полигонами в базу данных sqlite
- при помощи библиотеки SpatiaLite и поставляемых ею специфических гис-функций (список с описанием: http://www.gaia-gis.it/gaia-sins/spatialite-sql-3.0.0.html ), получать ответ на вопрос "в какой полигон попадает точка с координатами X,Y"
Надо-ка будет присмотреться по-внимательнее. |
|
|
|
(0006993)
|
|
zOn
|
12-05-2012 06:14
(edited on: 12-05-2012 06:42) |
|
А Навителовские никто не пробовал курочить?
файлик прикрепил
а это http://support.microsoft.com/kb/888253 никак не поможет? может из винды можно брать файлик?
|
|
|
|
(0007000)
|
|
zed
|
|
12-05-2012 18:33
|
|
>А Навителовские никто не пробовал курочить?
>файлик прикрепил
Хм, что-то довольно компактное. Если бы ещё знать, что там за формат. |
|
|
|
|
>Если бы ещё знать, что там за формат.
Сильно подозреваю что там скомпилённый в бинарный вид текст вот такой базы - http://ru.wikipedia.org/wiki/Tz_database
Она поставляется типа в виде текстов (с сайта IANA, подразделение ICANN), но размер у них ... 680КБ. И не уверен что есть границы временных зон, скорее они дают параметры времени по некоторым населённым пунктам есть (зато даже с историей смен параметров времени!). |
|
|
|
(0009607)
|
|
zed
|
|
20-10-2012 14:07
|
|
|
Написал dll, при помощи которой надеюсь решить данный тикет. В dll лежат округлённые и прореженные границы тайм зон. Весит она около 3 Мб и добавлять её нужно будет самостоятельно (выложу чуть позже). Т.е. нету dll - показывает по-старинке, есть - по уточнённым данным. |
|
|
|
(0009610)
|
|
Tolik
|
20-10-2012 16:04
(edited on: 20-10-2012 16:08) |
|
А можно посмотреть эти округлённые и прореженные границы тайм зон в виде kmz?
Насколько сложно будет изменить эти границы по мере смены настроения президентов?
Предлагаю убрать "показ по старинке", т.к. он врёт чуть более чем всегда. Нет dll - нет фичи (не показывать часы вообще или показывать системное время).
|
|
|
|
(0009611)
|
|
zed
|
|
20-10-2012 16:32
|
|
>А можно посмотреть эти округлённые и прореженные границы тайм зон в виде kmz?
Ну, теоретически могу сгенерировать и kml, если надо.
>Насколько сложно будет изменить эти границы по мере смены настроения президентов?
Актуализировать dll можно минут за пять, с учётом траты времени на загрузку новых границ и описаний тайм-зон. Исходники dll и вспомогательной утилитки для её актуализации будут выложены в паблик, так что моё участие в обновлении dll будет даже не обязательно - собрать сможет любой желающий, по мере необходимости. |
|
|
|
(0009612)
|
|
bk99
|
|
20-10-2012 16:59
|
|
> Предлагаю убрать "показ по старинке", т.к. он врёт чуть более чем всегда. Нет
> dll - нет фичи (не показывать часы вообще или показывать системное время).
Да, лучше убрать. Так, как это реализовано сейчас, лишь вводит в заблуждение т.к. даёт ложную информацию, которой веришь. Было бы правильнее при отсутствии длл-ки вместо часов показывать что-то типа "no timezones.dll" и всплывающую подсказку (при наведении мыши) куда идти и что делать. |
|
|
|
(0009613)
|
|
zed
|
|
20-10-2012 17:20
|
|
Приложил для тестов:
- TimeZone_Compact_2.7z - значения градусов округлены до 2-х знаков после запятой, полигоны с числом точек более 1000 сильно прорежены (чем больше полигон, тем он сильнее прорежен)
- TimeZone_Full_2.7z - аналогично предыдущему, но без какого-либо специального прореживания
- TimeZone_Full_4.7z - округление до 4-х знаков после запятой, без спец. прореживания
Ну и exe, где активирована эта функция.
Как использовать: dll распаковать в директорию с САС и переименовать в TimeZone.dll
Значения, которые получаются из dll будут уже с указанием смещения относительно UTC.
Наихудший момент, с точки зрения производительности, это когда идёт переход от какой-либо известной тайм-зоны на водную поверхность (тайм-зона не определена и берётся из старого метода).
Замеченный недостаток: из-за прореживания полигонов в следствии округления либо из-за спец. прореживания (особенно) возможны моменты, когда на стыке двух тайм-зон не удаётся определить текущую тайм-зону (точка попадает в слепую зону между двух полигонов).
И чисто для информации: специально введён интервал в 0,5 сек. ограничивающий запросы к dll, чтобы не падала производительность при быстром перемещении курсора (особенно на малых зумах типа "весь мир"), поэтому возможна небольшая инерционность. |
|
|
|
(0009614)
|
|
Tolik
|
20-10-2012 18:26
(edited on: 20-10-2012 19:44) |
|
> на загрузку новых границ и описаний тайм-зон
Какие данные используются и откуда их загружать?
> могу сгенерировать и kml, если надо
Да, пожалуйста, очень интересно. С разными вариантами округления.
|
|
|
|
(0009615)
|
|
zed
|
|
20-10-2012 18:37
|
|
|
|
|
(0009616)
|
|
Tolik
|
|
20-10-2012 18:41
|
|
Загрузил exe и самый большой dll.
Показывает правильно, не тормозит (правда, ноут мощный).
Пробел после UTC лучше убрать (UTC+4).
Не нравится, что в морях показывает что попало, например:
в Англии 19:30 (UTC+1) - правильно (там летнее время)
в проливе 18:30 - неправильно
во Франции 20:30 (UTC+2) -правильно. |
|
|
|
(0009617)
|
|
Tolik
|
20-10-2012 18:44
(edited on: 20-10-2012 18:57) |
|
В Индии время показывает правильно, а таймзону неправильно: (UTC +6) вместо (UTC+5:30).
В Непале то же: (UTC +6) вместо (UTC+5:45).
|
|
|
|
(0009618)
|
|
Tolik
|
20-10-2012 18:51
(edited on: 20-10-2012 18:55) |
|
|
|
|
(0009619)
|
|
zed
|
|
20-10-2012 19:07
|
|
>Не нравится, что в морях показывает что попало
В морях и незаселённых территориях временные зоны считаются чисто условно, я приводил выше цитату. |
|
|
|
(0009620)
|
|
Tolik
|
20-10-2012 19:13
(edited on: 20-10-2012 19:17) |
|
Я это заметил, потому и полез сразу проверять моря.
Слепую зону тоже посмотрел (TimeZone_Compact_2.7z): на границе России и Беларуси (N54°49'14.61" E30°49'36.65") размер слепой зоны больше 10 км. Слишком много.
А вот с TimeZone_Full_2.7z навскидку слепой зоны не заметил, так что это, пожалуй, оптимальный вариант (6 МБ).
|
|
|
|
(0009621)
|
|
Tolik
|
20-10-2012 19:33
(edited on: 20-10-2012 19:34) |
|
Ошибку (см. elf) поймал так: двигал курсор с моря на сушу и обратно несколько раз в районе Рио.
|
|
|
|
(0009624)
|
|
zed
|
|
20-10-2012 21:21
|
|
С UTC вроде бы разобрался, теперь должно показывать всюду верно. Исправления будут в сегодняшней ночнушке.
>Ошибку (см. elf) поймал так
Ага, и я такую же ловил, но это что-то компонент ругается. Время вроде нормальное в мессадже, не пойму что его не устраивает. |
|
|
|
(0009625)
|
|
Tolik
|
|
21-10-2012 04:08
|
|
В ночнушке 121021.6591 UTC в порядке, ошибка не воспроизводится (надо в 23:30 попробовать).
Может, попробовать округление до 1 знака без прореживания? |
|
|
|
(0009629)
|
|
zed
|
|
21-10-2012 10:38
|
|
>Может, попробовать округление до 1 знака без прореживания?
Приложил TimeZone.x1.7z |
|
|
|
(0009630)
|
|
Tolik
|
|
21-10-2012 11:24
|
|
|
TimeZone.x1.7z тоже работает нормально, но погрешность 0.1 градуса - всё-таки много, так что я выбираю TimeZone_Full_2.7z |
|
|
|
(0009631)
|
|
zed
|
21-10-2012 11:35
(edited on: 30-12-2012 18:52) |
|
|
|
|
(0009633)
|
|
zed
|
21-10-2012 12:58
(edited on: 30-12-2012 18:53) |
|
|
|
|
(0009634)
|
|
Tolik
|
21-10-2012 13:28
(edited on: 21-10-2012 13:31) |
|
Спасибо за kml.
x3 практически не отличается от x4 и по размеру файла, и по форме полигонов, так что смысла в нём нет.
x1 слишком грубо, как я уже писал.
|
|
|
|
(0009635)
|
|
Tolik
|
|
21-10-2012 13:49
|
|
Есть ещё какой-то гистерезис.
Например, при движении вниз переход происходит здесь 54.944744° 30.876914°, а при движении вверх - здесь 54.955243° 30.877687°
Расстоянием между этим точками - 1 км.
Неужто так и задумано? Зачем? |
|
|
|
(0009636)
|
|
zed
|
|
21-10-2012 13:54
|
|
>Неужто так и задумано? Зачем?
Да. В целях уменьшения запросов к dll и увеличения быстродействия. Координаты от мышки кэшируются с округлением до второго знака после запятой. |
|
|
|
(0009638)
|
|
Tolik
|
|
21-10-2012 14:54
|
|
|
Так ведь он запрашивается раз в пол-секунды, разве этого ограничения недостаточно? |
|
|
|
(0009639)
|
|
zed
|
|
21-10-2012 15:02
|
|
|
Могу загрубить до 4-х знаков, если сильно мешает. Петля гистерезиса всё-равно останется, но в меньших размерах (метров 100?). |
|
|
|
(0009641)
|
|
zed
|
|
21-10-2012 16:10
|
|
|
Всё, завтрашняя ночнушка будет работать только с dll. Если её найти не удаётся - инфа о времени/таймзонах отключается, чекбоксы становятся не активными с объяснением причины. |
|
|
|
(0009644)
|
|
Tolik
|
21-10-2012 16:17
(edited on: 21-10-2012 16:18) |
|
Хорошо, пусть будет до 4-х знаков. Метров 100 - это нормально, никто и не заметит.
А то полигоны округляются до 4-х, а смысл? :)
|
|
|
|
(0009645)
|
|
zed
|
|
21-10-2012 16:18
|
|
|
|
|
(0009652)
|
|
Tolik
|
|
22-10-2012 04:12
|
|
|
Надо внутри архивов переименовать dll, чтобы не приходилось это делать руками. Это вызовет массу вопросов. Также надо где-то в программе добавить ссылку на архив и подсказку, что именно скачивать (там 8 файлов, а нужен только один: какой?) |
|
|
|
(0009662)
|
|
zed
|
|
22-10-2012 07:56
|
|
|
В релизе dll будет в комплекте, а для пользователей ночнушек можно в wiki написать небольшую заметку. |
|
|
|
(0009663)
|
|
Tolik
|
|
22-10-2012 07:58
|
|
|
|
|
(0011402)
|
|
zed
|
|
19-05-2013 11:56
|
|
|
|
|
(0020047)
|
|
zed
|
|
24-01-2021 13:15
|
|
Библиотека TimeZone.dll сменила имя и прописку. Теперь это libtz.dll https://github.com/zedxxx/libtz/releases
Кроме того, теперь она будет включена и в архивы с ночной версией. |
|
3.csv (9,377) 28-02-2012 15:00
3.kml (561,965) 28-02-2012 15:01