- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
time_t t = time(NULL);
struct tm tm = *localtime(&t);
char day[3], month[3], year[5], toDay[15] = "";
//converting time ints to strings.
sprintf(day, "%d", tm.tm_mday);
sprintf(month, "%d", (tm.tm_mon + 1));
sprintf(year, "%d", tm.tm_year + 1900);
//string connecting.
strcat(toDay, day);
strcat(toDay, "/");
strcat(toDay, month);
strcat(toDay, "/");
strcat(toDay, year);
man strftime, блджад.
#undef UINT64_MAX
#endif
#define UINT64_MAX 19417
Есть пиндосский мм/дд/гггг.
Есть наш дд.мм.гггг.
Есть исошный гггг-мм-дд.
А дд/мм/гггг - какой-то кентавр, который только путаницу и разброд вносит. Особенно если там 02/02/2016.
Евrопейский
1с и прочие обязаны делать правильно для бухгалтерии (и прочие официальные документы), где по закону надо местному стандарту следовать.
меня лично в этой теме всегда напрягало что нет деления: human readable vs официальный формат. я пару раз локаль переконфигурировал в офисе что бы время/даты читабельнее для меня лично были. пидорастичный винворд послушно во всех документах которые я редактировал формат автоматом поменял. один раз я почти релиз "сломал" тем что в официальном документе (я менял его последним) даты были в неправильном формате.
с одной стороны, их лексикографический порядок соответствует календарному, с другой -- выглядит как сраная криптография, особенно когда подобный таймстемп используется в составе какого-нибудь идентификатора
Так они ещё и разыгрываются?! Т.е. просто не грешить недостаточно, надо ещё и хорошее везение?