On 07/12/2023 23:08, tomas wrote:
On Thu, Dec 07, 2023 at 10:29:29PM +0700, Max Nikulin wrote:
On 07/12/2023 21:22, John Hasler wrote:
Databases should never store local time.
There are exceptions when storing UTC instead of local time leads to
undesired consequences.
Heh. There was one huge thread in Emacs user about a year ago (don't
ask me in which time zone).
Perhaps you mean emacs-ormode. Then an important difference arises.
Timestamp are stored not in a database, but in a plain text file and
must be human readable, moreover some users prefer to type timestamps
directly without dedicated commands.
Leaving aside future timestamps that may need local time, significant
fraction of timestamps may be reliably represented in UTC. I still have
no clue why some people were strongly against local time with explicit
time offset "2023-12-07 17:08:50 +0100". From my point of view such
format may be unambiguously mapped to UTC "2023-12-07T16:08:50Z" and
more convenient for users residing in Europe/Berlin. There were
participants insisting on either forcing UTC or using IANA identifiers
"2023-12-07 17:08:50 Europe/Berlin". The latter format has issues close
to backward DST time shifts and should be augmented with disambiguation
hints.
After having a long and fruitless discussion with a customer (they
insisted in having local time in a log file, which is almost always
the wrong thing) I came to the conclusion that in such situations
it's best to give them what they want -- but store time zone *and*
time offset with it.
Local time is widely used in logs. The question is if the client can
accept ambiguity
LANG=C.UTF-8 TZ=Europe/Berlin date -d 'TZ="Z" 2023-10-29 00:30' '+%F %T'
2023-10-29 02:30:00
LANG=C.UTF-8 TZ=Europe/Berlin date -d 'TZ="Z" 2023-10-29 01:30' '+%F %T'
2023-10-29 02:30:00
That are
LANG=C.UTF-8 TZ=Europe/Berlin date -d 'TZ="Z" 2023-10-29 00:30' '+%F %T
%z %Z'
2023-10-29 02:30:00 +0200 CEST
LANG=C.UTF-8 TZ=Europe/Berlin date -d 'TZ="Z" 2023-10-29 01:30' '+%F %T
%z %Z'
2023-10-29 02:30:00 +0100 CET
Another case to consider it integration with 3rd party log analyzing
tools and time formats that they can parse.
As I said above I see nothing wrong in local time with explicit time
offset. Mail has been using it for decades:
Date: Thu, 7 Dec 2023 17:08:50 +0100
