Який улюблений формат дати та часу в назві файлу? [зачинено]


88

Це дещо суб’єктивне питання, і не дуже важливе у великій схемі речей, але те, що все ж мене регулярно дратує. Здається, немає зрозумілого способу поставити позначку часу в назві файлу .

Об’єктивна проблема полягає в тому, що мітки часу в іменах файлів повинні сортуватися . Але сортувальні формати дат .NET, такі як "s" ( "yyyy-MM-ddTHH:mm:ss") та "u" ( "yyyy-MM-dd HH:mm:ssZ"), не є дійсними в іменах файлів через символи ':'.

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

Я в основному використовував ISO 8601 з основним форматом часу:

  • Рядок формату місцевого часу "yyyy-MM-ddTHHmmsszz"
  • Рядок формату UTC "yyyy-MM-ddTHHmmssZ"

У цих форматах моїм поточним місцевим часом буде "2009-08-08T151800+03"UTC"2009-08-08T121800Z"

Ви також можете автоматично визначити DateTime.Kind за допомогою "K" і використовувати "yyyy-MM-ddTHHmmssK", але тоді вам доведеться замінити символи ':'.

Будь-які інші пропозиції?

Змінити: Поки що кілька приміток:

Формат місцевого часу + часовий пояс "yyyy-MM-ddTHHmmsszz"більше не можна сортувати, якщо задіяно кілька часових поясів. У більшості випадків має сенс упустити інформацію про часовий пояс, якщо вона зайва, а в іншому випадку використовувати UTC.

Інша справа, що UTC завжди повинен бути позначений „Z”, „GMT” або „UTC”, щоб запобігти здогадкам та помилкам.

Джуліанські дати та інші зоряні дати - це круто, тому що арифметика дат за григоріанським календарем є розумовою.


2
Я згоден з усім цим , за винятком , що я дійсно вважаю важливим у великій схемі речей. Ваш формат найкращий - я б навіть використовував 4-значний часовий пояс, як зазначено у ISO8601, для розміщення нецілих зон. Мене завжди турбувало те, що ISO8601 не стосується забороненої двокрапки в іменах файлів.
hpekristiansen

Я пропоную формат, заснований на ISO 8601, у дописі на blog.xam.de/2016/07/… - полегшив би наш світ, якби ми могли домовитись про формат :-)
д-р Макс Волкель,

"закритий як неконструктивний" ?? Є причини і проти кожного пропозиції, так що це є конструктивним. Не потрібно
цуратися

Відповіді:


57

Я використовую це:

My-File--2009-12-31--23-59-59.txt
  • Без пробілів
  • Подвійні риски, щоб розділити шматочки, що робить кожен шматок легким для перегляду
  • Лише один розділовий символ (тире), що полегшує друк
  • Жодного часового поясу, тому що для мене я завжди працюю за місцевим часовим поясом; якщо мені потрібен, я піду з UTC і додаю " --UTC" через час.

5
Я роблю приблизно те ж саме, хоча я починаю з позначки часу, а потім "my-file", оскільки це дозволяє переглядати файли в хронологічному порядку, просто впорядковуючи імена файлів за алфавітом.
ChristopheD

2
@ChristopheD: Звичайно - я б зробив те саме в такому випадку. Для своєї відповіді я думав про випадок, коли у вас є кілька версій декількох різних файлів, і ви хочете, щоб вони були згруповані за назвою файлу.
RichieHindle

2
Особисто я віддаю перевагу використовувати підкреслення ( _) замість подвійного тире для розділення фігур. (напр. My-File_2009-12-31_23-59-59.txt)
Елі Г.

A name_-_2019-11-04--15-04-36.642621403_-_2019-11-04--15-04-36.642622803.ext- це нормально для оболонки Linux. Без часового поясу, але з точністю до наносекунд.
Іван Чорний

14

Я б використовував YYYY-MM-DD HHmmssдля імен файлів, якщо немає особливої ​​потреби в часових поясах або можливою необхідності їх синтаксичного аналізу на дати ISO; у цих випадках дата ISO, мабуть, була б кращою.

Редагувати: часові пояси насправді ніколи не вимагатимуться; зберігати все в UTC і давати людям зрозуміти, що це все UTC, ефективніше, ніж вказати часовий пояс усього.


9
ну, пробіли у ваших назвах файлів?
Саггі Малахі

10
Що не так з пробілами?
Джої

41
Так, простори мерзенні. Я особисто
відшукую

1
@Saggi; ну я, мабуть, на це заслужив, але серйозно - покажіть мені одну систему, яка не обробляє імена файлів з пробілами? З того, що я міг зібрати, не було задіяно URI, і, отже, я не надто турбуюся про пробіли. Звичайно, ви можете обміняти цей простір на щось інше, наприклад, підкреслення або T, але це менш природно, коли ви його читаєте.
Ви

1
Я проголосую за цей (але я ніколи не буду використовувати пробіли), причиною є 4-значний рік, який відкладе проблему y2k1 (але не y10k, але хто насправді дає XXXX про це?).
paxdiablo

8

Ось що я використовую:

    private static string CreateMeaningfulFileName(string friendlyName, DateTime date)
    {
        StringBuilder sb = new StringBuilder();
        foreach (string s in friendlyName.Split(new char[] { ' ' }))//remove spaces
        {
            sb.Append(CultureInfo.CurrentCulture.TextInfo.ToTitleCase(s.ToLower()));//capitalize each segment
        }
        sb.Append("_" + date.ToString("yyyy-MM-dd_HH-mm"));//add date
        return sb.ToString();
    }

Для цього потрібні дата та опис. Давайте використаємо "Мені подобаються СОБАКИ". Призводить до:

ILikeDogs_1999-09-23_18-42


1
Хороший спосіб розбити дату та час і на 1 символ менше, ніж відповідь @ RichieHindle.
Robino

3

Чи існує вимога, щоб мітка часу була зручною для читання? Якщо ні, ви можете просто використовувати DateTime.Ticks.ToString () . Дуже влучний, сортується і не має особливих символів.


1
Я схильний намагатися зробити все, щоб це було зрозумілим для людей, якщо це можливо. Це одне з найбільших значень таких схем, як позначення JSON. Навіть якщо ви не думаєте, що це повинно бути зрозумілим для людей, ви ніколи не знаєте, чи хочете ви, щоб це було зручно читати пізніше. Крім того, це, як правило, полегшує налагодження.
Едан Маор

Посилання недоступне, на що воно пішло?
rbatt

@rbatt Я думаю, що це була лише тимчасова проблема MSDN - вона повинна повернутися зараз.
Dan Diplo

2

Зазвичай я використовую yyyymmdd. Якщо потрібна подальша точність, вона змінюється на yyyymmddhhmmss


1

Я використовую мітки часу unix, наприклад. скільки секунд минуло від епохи. Весь час у UTC. Але припустимо, ви можете, якщо хочете, вказати префікс до даних часового поясу.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.