On 7/12/26 03:54, MG wrote:
@Convenience variant:
1. Suggestion for date/date-time/timestamp formats:
1. yyyy-MM-dd
2. yyyy-MM-dd HH:mm:ss
3. yyyy-MM-dd HH:mm:ss.SSS
1. e.g.: 2026-12-31 23:59:59.999
4. Rationale: Easy to read, logical order (no year-day-month), no
am/pm, no named month ("July") etc
2. Consider having UTC variants:
1. Rationale: Works everywhere, avoids all summer-/winter time
problems, makes timestamps universally comparable, so can be
very convenient/helpful in certain situations, e.g. when peopl
from different continents have to read the same log file.
I use UTC, if possible, in my programs always UTC for log files and
such. date-time conversions can be such a pain.
Just for people that read here and usually do not face those problems:
Assume for example you have an application where you allow customers in
your shop to win a price, but because of regulations the person must be
18 years old. Now the question is "when is somebody 18 years old"? When
I last faced this it was interpreted as on the date of birth plus 18
years. Now assume it is 1 minute past midnight. The birth date of that
person is "today". But you are in a different timezone than where the
place of birth is put in. You could play it safe and say 18 years plus 1
day, enrage the birthday kid and loose a potential customer that may
spread that information that he was denied on his birthday. Or you try
to deal with the issue by trying to find out in what timezone that place
of birth is at the time of birth (yes timezone designations can change
for political reasons).
Sounds all crazy, I know. But this was a real life problem to solve.
bye Jochen
