Re: GROOVY-12147 and default locales

On 7/12/26 03:54, MG wrote:
> @Convenience variant:
>=20
>  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=20
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=20
your shop to win a price, but because of regulations the person must be=20
18 years old. Now the question is "when is somebody 18 years old"? When=20
I last faced this it was interpreted as on the date of birth plus 18=20
years. Now assume it is 1 minute past midnight. The birth date of that=20
person is "today". But you are in a different timezone than where the=20
place of birth is put in. You could play it safe and say 18 years plus 1=
=20
day, enrage the birthday kid and loose a potential customer that may=20
spread that information that he was denied on his birthday. Or you try=20
to deal with the issue by trying to find out in what timezone that place=
=20
of birth is at the time of birth (yes timezone designations can change=20
for political reasons).

Sounds all crazy, I know. But this was a real life problem to solve.

bye Jochen