Это перевод To be a leader you must know when to follow. Автор: Реймонд Чен.
Многие люди неверно поняли моё использование термина "reluctant" ("вынуждено", "с неохотой") для описания отношения дизайнеров UI к изменению способа работы диалога дата/время. Это было нежелание стыда, а не нежелание неповиновения.
...when altering one's mind becomes as easy as programming a computer, what does it mean to be human?..
Показаны сообщения с ярлыком дата/время. Показать все сообщения
Показаны сообщения с ярлыком дата/время. Показать все сообщения
пятница, 18 февраля 2011 г.
воскресенье, 13 февраля 2011 г.
Как распознать различные специальные значения меток времени
Это перевод How to recognize different types of sentinel timestamps from quite a long way away. Автор: Реймонд Чен.
Когда-то я обсуждал различные форматы времени, с которыми вы можете встретиться на практике. Сегодня мы сделаем следующий логический шаг и построим список значений, с которыми вы можете встретиться. Заметьте, что если при этом применяется подстройка под часовую зону, то реальная метка времени может отличаться на +/- день максимум.
Когда-то я обсуждал различные форматы времени, с которыми вы можете встретиться на практике. Сегодня мы сделаем следующий логический шаг и построим список значений, с которыми вы можете встретиться. Заметьте, что если при этом применяется подстройка под часовую зону, то реальная метка времени может отличаться на +/- день максимум.
суббота, 17 июля 2010 г.
Апплет Дата/Время не является календарём
Это перевод The Date/Time control panel is not a calendar. Автор: Реймонд Чен.
Хотя многие люди используют апплет Дата/Время Панели управления как календарик, перелистывая страницы с месяцами - это не то, для чего он предназначается. Фактически, если вы когда-либо использовали его подобным образом, вы могли создать хаос на своей машине!
Хотя многие люди используют апплет Дата/Время Панели управления как календарик, перелистывая страницы с месяцами - это не то, для чего он предназначается. Фактически, если вы когда-либо использовали его подобным образом, вы могли создать хаос на своей машине!
суббота, 27 июня 2009 г.
Почему Windows хранит время в BIOS в локальном формате?
Это перевод Why does Windows keep your BIOS clock on local time? Автор: Реймонд Чен.
Хотя Windows NT внутри себя использует UTC время, часы BIOS остаются на местном (локальном) времени. Почему так делается?
На это есть несколько причин. Одна из них - цепочка из обратных совместимостей.
Хотя Windows NT внутри себя использует UTC время, часы BIOS остаются на местном (локальном) времени. Почему так делается?
На это есть несколько причин. Одна из них - цепочка из обратных совместимостей.
понедельник, 22 июня 2009 г.
Почему структуру TFileTime нельзя рассматривать как Int64?
Это перевод Why can't you treat a FILETIME as an __int64? Автор: Реймонд Чен.
Запись TFileTime представляет 64-х битное значение в двух частях:
Вы можете поддаться соблазну взять запись TFileTime и обращаться с ней, как если бы она была типа Int64. В конце концов, её раскладка по памяти в точности совпадает с отпечатком памяти для 64-х битного (little-endian) Integer. Некоторые люди написали пример кода, который делает именно это.
Но почему это неверно?
Запись TFileTime представляет 64-х битное значение в двух частях:
type
PFileTime = ^TFileTime;
_FILETIME = record
dwLowDateTime: DWORD;
dwHighDateTime: DWORD;
end;
TFileTime = _FILETIME;
FILETIME = _FILETIME;
Вы можете поддаться соблазну взять запись TFileTime и обращаться с ней, как если бы она была типа Int64. В конце концов, её раскладка по памяти в точности совпадает с отпечатком памяти для 64-х битного (little-endian) Integer. Некоторые люди написали пример кода, который делает именно это.
Но почему это неверно?
среда, 7 января 2009 г.
Почему меняется метка времени файла, когда я копирую его на дискету?
Это перевод Why do timestamps change when I copy files to a floppy? Автор: Реймонд Чен.
Дискеты используют файловую систему FAT - так же, как и DOS или Windows 95. С другой стороны, системы на базе Windows NT (Windows 2000, XP, 2003, ...) обычно используют файловую систему NTFS (хотя вы можете отформатировать свой диск в FAT и на Windows NT системе, но это не поведение по-умолчанию).
Файловые системы NTFS и FAT хранят время и дату разными способами. Заметим, например, что FAT отмечает время последней записи (last-write time) только с двухсекундной точностью. Поэтому, если вы копируете файл с NTFS-диска на FAT-диск, то время файла может измениться, но не более, чем на две секунды.
Дискеты используют файловую систему FAT - так же, как и DOS или Windows 95. С другой стороны, системы на базе Windows NT (Windows 2000, XP, 2003, ...) обычно используют файловую систему NTFS (хотя вы можете отформатировать свой диск в FAT и на Windows NT системе, но это не поведение по-умолчанию).
Файловые системы NTFS и FAT хранят время и дату разными способами. Заметим, например, что FAT отмечает время последней записи (last-write time) только с двухсекундной точностью. Поэтому, если вы копируете файл с NTFS-диска на FAT-диск, то время файла может измениться, но не более, чем на две секунды.
пятница, 28 ноября 2008 г.
Почему летнее время не интуитивно
Это перевод Why Daylight Savings Time is nonintuitive. Автор: Реймонд Чен.
На этой неделе заканчивается действие летнего времени в большей части Северной Америки и Европы, поэтому это кажется мне отличным моментом, чтобы обсудить проблему летнего времени и меток времени.
Люди часто жалуются на то, что все функции преобразования временной зоны типа FileTimeToLocalFileTime используют текущее DST-смещение (Daylight Saving Time - летнее время) вместо смещения, которое действовало в рассматриваемое время.
Например, предположим, что у вас есть структура FILETIME (TFileTime), которая представляет "1 января 2000, 12:00 AM". Если вы будете в Редмонде в летнее время, то структура будет сконвертирована в "31 декабря 1999, 5:00 PM" - с разницей в 7 часов, хотя разница во времени между Редмондом и UTC в Новый Год была 8 часов (т.е. когда люди в Лондоне праздновали Новый Год, в Редмонде было 4 PM, а не 5 PM).
Причина в том, что время переводится из "1 января 2000, 12:00 AM UTC" в "31 декабря, 1999 5:00 PM PDT" (т.е. переводит в тихоокеанское летнее время). Поэтому, технически, это преобразование корректно. Конечно же, никто не использовал PDT 31-го декабря 1999 в Редмонде; все использовали PST (тихоокеанское зимнее время).
Почему бы функциям перевода времени не использовать подходящее смещение в зависимости от времени года?
Одной причиной будет то, что тогда FileTimeToLocalFileTime и LocalFileTimeToFileTime не будут противоположностью друг другу. Если у вас будет местное время в пределах "пропавшего часа" во время перевода со стандартного на летнее время, то у него не будет соответствующего UTC-времени, потому что тогда не было 2:30 AM (часы перепрыгнули с 2 AM на 3 AM). Аналогично, местное время в 2:30 AM во время перехода обратно будет иметь два соответствующих UTC-времени.
Другая причина - постоянное изменение законов, регулирующих переход на летнее время. Например, если бы год в примере был бы не 2000, а 1997-й, то перевод был бы и интуитивно правильным, потому что Соединённые Штаты были на летнем времени весь год из-за энергетического кризиса. Конечно же, такая информация нигде не записывается в структуре TIME_ZONE_INFORMATION (TTimeZoneInformation). Похожим образом, во время Второй Мировой Соединённые Штаты использовали летнее время круглый год. А между 1945 и 1966 DST-правила менялись от региона к региону.
DST-правила меняются даже сегодня. Время перевода часов в Израиле устанавливается Кнессетом каждый год. В результате не существует единой формулы для каждого дня, нет возможности узнать её раньше времени.
(Предупреждение: дальше идёт материал о .NET; это уже второй день подряд, и что на меня нашло!?)
Сравните вывод FileInfo.LastWriteTime.ToString('f') с тем, что вы видите на вкладчке свойств файла, который последний раз изменялся не в той же зоне, что действует сейчас (т.е. если сейчас зимнее время, то посмотрите файл, созданный летом и наоборот). Например, пусть файл модифицировался последний раз 17-го Октября, когда ещё действовало летнее, но сейчас действует зимнее время. В свойствах файла в Проводнике вы увидите "Четверг, 17 октября 2003 г., 8:45:38 AM", но FileInfo из .NET сообщит о "Четверг, 17 октября 2003 г., 9:45 AM".
En gang til for prins Knud: Win32 не пытается угадывать, какие правила для времени действовали в указанное время. Поэтому Win32 говорит "Четверг, 17 октября 2003 г., 8:45:38 AM PST". Заметьте: Pacific Standard Time (зимнее время). Даже хотя 17-го октября действовало летнее время, Win32 отображает его как зимнее, потому что именно это то время, что действует сейчас.
.NET говорит: "ну, если правила, действующие сейчас, действовали бы и 17 октября 2003-го, то тогда это было бы летнее время", поэтому .NET показывает: "Четверг, 17 октября 2003 г., 9:45 AM PDT" - летнее время.
Итак, .NET даёт значение, которое более правильно интуитивно, но также может быть потенциально неверным, и, кроме того, не всегда обратимым. Win32 даёт интуитивно неверное значение, которое, тем не менее, является строго точным.
Я подозреваю, что такое поведение в .NET введено для совместимости с Visual Basic, но тут я точно не уверен.
Добро пожаловать читатели Knowledge Base article 932955! Помните, что информация на этом вэб-сайте не является официальной документацией Microsoft.
На этой неделе заканчивается действие летнего времени в большей части Северной Америки и Европы, поэтому это кажется мне отличным моментом, чтобы обсудить проблему летнего времени и меток времени.
Люди часто жалуются на то, что все функции преобразования временной зоны типа FileTimeToLocalFileTime используют текущее DST-смещение (Daylight Saving Time - летнее время) вместо смещения, которое действовало в рассматриваемое время.
Например, предположим, что у вас есть структура FILETIME (TFileTime), которая представляет "1 января 2000, 12:00 AM". Если вы будете в Редмонде в летнее время, то структура будет сконвертирована в "31 декабря 1999, 5:00 PM" - с разницей в 7 часов, хотя разница во времени между Редмондом и UTC в Новый Год была 8 часов (т.е. когда люди в Лондоне праздновали Новый Год, в Редмонде было 4 PM, а не 5 PM).
Причина в том, что время переводится из "1 января 2000, 12:00 AM UTC" в "31 декабря, 1999 5:00 PM PDT" (т.е. переводит в тихоокеанское летнее время). Поэтому, технически, это преобразование корректно. Конечно же, никто не использовал PDT 31-го декабря 1999 в Редмонде; все использовали PST (тихоокеанское зимнее время).
Почему бы функциям перевода времени не использовать подходящее смещение в зависимости от времени года?
Одной причиной будет то, что тогда FileTimeToLocalFileTime и LocalFileTimeToFileTime не будут противоположностью друг другу. Если у вас будет местное время в пределах "пропавшего часа" во время перевода со стандартного на летнее время, то у него не будет соответствующего UTC-времени, потому что тогда не было 2:30 AM (часы перепрыгнули с 2 AM на 3 AM). Аналогично, местное время в 2:30 AM во время перехода обратно будет иметь два соответствующих UTC-времени.
Другая причина - постоянное изменение законов, регулирующих переход на летнее время. Например, если бы год в примере был бы не 2000, а 1997-й, то перевод был бы и интуитивно правильным, потому что Соединённые Штаты были на летнем времени весь год из-за энергетического кризиса. Конечно же, такая информация нигде не записывается в структуре TIME_ZONE_INFORMATION (TTimeZoneInformation). Похожим образом, во время Второй Мировой Соединённые Штаты использовали летнее время круглый год. А между 1945 и 1966 DST-правила менялись от региона к региону.
DST-правила меняются даже сегодня. Время перевода часов в Израиле устанавливается Кнессетом каждый год. В результате не существует единой формулы для каждого дня, нет возможности узнать её раньше времени.
(Предупреждение: дальше идёт материал о .NET; это уже второй день подряд, и что на меня нашло!?)
Сравните вывод FileInfo.LastWriteTime.ToString('f') с тем, что вы видите на вкладчке свойств файла, который последний раз изменялся не в той же зоне, что действует сейчас (т.е. если сейчас зимнее время, то посмотрите файл, созданный летом и наоборот). Например, пусть файл модифицировался последний раз 17-го Октября, когда ещё действовало летнее, но сейчас действует зимнее время. В свойствах файла в Проводнике вы увидите "Четверг, 17 октября 2003 г., 8:45:38 AM", но FileInfo из .NET сообщит о "Четверг, 17 октября 2003 г., 9:45 AM".
En gang til for prins Knud: Win32 не пытается угадывать, какие правила для времени действовали в указанное время. Поэтому Win32 говорит "Четверг, 17 октября 2003 г., 8:45:38 AM PST". Заметьте: Pacific Standard Time (зимнее время). Даже хотя 17-го октября действовало летнее время, Win32 отображает его как зимнее, потому что именно это то время, что действует сейчас.
.NET говорит: "ну, если правила, действующие сейчас, действовали бы и 17 октября 2003-го, то тогда это было бы летнее время", поэтому .NET показывает: "Четверг, 17 октября 2003 г., 9:45 AM PDT" - летнее время.
Итак, .NET даёт значение, которое более правильно интуитивно, но также может быть потенциально неверным, и, кроме того, не всегда обратимым. Win32 даёт интуитивно неверное значение, которое, тем не менее, является строго точным.
Я подозреваю, что такое поведение в .NET введено для совместимости с Visual Basic, но тут я точно не уверен.
понедельник, 24 ноября 2008 г.
Как распознать тип отдельно взятой временной метки
Это перевод How to recognize different types of timestamps from quite a long way away. Автор: Реймонд Чен. Примечание: в отличие от других постов, этот пост сильно отличается от оригинала. Произведено множество замен от C к Delphi.
Одной из хороших сторон меток времени является количество их форматов, из которых мы можем выбирать. Иногда во время отладки (или при чтении неполной документации) вы можете наткнуться на значение метки времени и задуматься, как перевести его во что-нибудь читабельное. Вот несколько подсказок.
Одной из хороших сторон меток времени является количество их форматов, из которых мы можем выбирать. Иногда во время отладки (или при чтении неполной документации) вы можете наткнуться на значение метки времени и задуматься, как перевести его во что-нибудь читабельное. Вот несколько подсказок.
среда, 12 ноября 2008 г.
Почему мой часовой пояс не показывается на мировой карте?
Это перевод Why isn't my time zone highlighted on the world map? Автор: Реймонд Чен. Входит в книгу The Old New Thing.
В первом выпуске Windows 95 вы могли сменить свой часовой пояс, выбрав его на карте. При этом, пояс, по которому вы щёлкнули, автоматически подсвечивался. Аналогичным образом, вы могли сменить свои региональные настройки просто щёлкнув в районе своего города на мировой карте. Это была одна из тех фишек, которые делали Windows 95 более простой в использовании.
Но нам пришлось убрать эти возможности всего через несколько месяцев после релиза, несмотря на то, что обе карты основывались на границах, официально признанными ООН.
В первом выпуске Windows 95 вы могли сменить свой часовой пояс, выбрав его на карте. При этом, пояс, по которому вы щёлкнули, автоматически подсвечивался. Аналогичным образом, вы могли сменить свои региональные настройки просто щёлкнув в районе своего города на мировой карте. Это была одна из тех фишек, которые делали Windows 95 более простой в использовании.
Но нам пришлось убрать эти возможности всего через несколько месяцев после релиза, несмотря на то, что обе карты основывались на границах, официально признанными ООН.
Подписаться на:
Сообщения (Atom)