What exactly is dangerous?

It is actually the right thing to do, so that the legacy file systems
(and a few other broken concepts) have the correct *local* timestamp not UTC
or some random one.

I believe you are mistaken on how the kernel timezone works.

The kernel does not have a zoneinfo database. Therefore, it can not take daylight saving time (DST) into account.

The offset the kernel applies to timestamps on legacy filesystems is constant, it is the offset corresponding to the instant the kernel timezone was set. As a consequence, the timestamps of the files created near that time are valid, but the timestamps of the files modified on the other side of the DST will be off by one hour.

For example, I am currently in CEST and my kernel booted this morning, that makes it at +0200. Files modified sometime between November and March would be in CET, not CEST, at +0100, but the kernel does not know that: therefore, their timestamps will appear off by one hour. Conversely, files that I modify today will appear off by one hour in the other direction if I mount them in six months.

The short of it is that it is NOT POSSIBLE to store timestamps in local time if there is no timezone indication (if only because the local time - UTC conversion is not a bijection), and it is EVEN LESS POSSIBLE without a zoneinfo database. Nobody serious would want a zoneinfo database in the kernel.

The current system produces usually correct timestamps for files created recently, and older files arguably do not need so much accuracy. This is probably good enough for most people, but not for people who actually use the timestamps, and not for me.

When living in a place with DST, the only reasonable thing to do is to store the timestamps in UTC. The conversion will happen in userspace, exactly as it happens for ext4 for example. That works perfectly (as long as the files are not modified on another OS; the Linux community can do nothing about that).

Selecting that option at each mount is error prone and not convenient, better to do it globally.

(For reference, I use the timestamps to synchronize a collection of files on an Android phone; due to Android, I can not use a better filesystem, but the timestamps are only used on systems that consider them UTC.)

Hmm, yeah, it is mess. We should try hard to avoid config options to
configure that mess though, and define an acceptable behaviour as the
way systemd as the OS works. We have several options:

- Teach systemd to update the kernel's TZ when DST changes; it is in the
  TODO, infrastruture for it is there, just not implemented. It will not be
  entirely race-free though, not sure if we really should try that ...

- Define that "local" is the time without DST, we just upload the
  local time without the DST offset; that way the kernel's "local" might
  be off by an hour, but still closer than UTC and not jumping. Very simple
  and maybe a reasonable compromise. not sure.

- Define that the kernel's "local" is so backwards, that the file systems,
  SCSI, netfilter are just too broken to be supported that way; that we just
  ignore all ideas of "local" and define the use UTC and accept hickups
  for multi-OS boots. Sounds a bit radical, but the most appealing of all
  options, to just not support that kind of stupidity in 2014.

> - Teach systemd to update the kernel's TZ when DST changes; it is in the
>   TODO, infrastruture for it is there, just not implemented. It will not be
>   entirely race-free though, not sure if we really should try that ...

I believe that IF setting the kernel timezone is considered necessary, then
updating it is undoubtedly the Right Thing.

But that will not help for filesystems timestamps: the kernel uses a
constant offset for the whole filesystem, and due to DST roughly half the
files are in the wrong timezone. Updating the timezone will only change what
offset is used: the one at boot time or the one at mount time.

> - Define that "local" is the time without DST, we just upload the
>   local time without the DST offset; that way the kernel's "local" might
>   be off by an hour, but still closer than UTC and not jumping. Very simple
>   and maybe a reasonable compromise. not sure.

I find this has the feel of a half measure. Also, it does not work when the
timezone changes for another reason (this is an argument I had not used
before), such as someone traveling (and updating the config accordingly) to
a different timezone.

> - Define that the kernel's "local" is so backwards, that the file systems,
>   SCSI, netfilter are just too broken to be supported that way; that we just
>   ignore all ideas of "local" and define the use UTC and accept hickups
>   for multi-OS boots. Sounds a bit radical, but the most appealing of all
>   options, to just not support that kind of stupidity in 2014.

I wholeheartedly support that solution, but I may be biassed by the facts
that I do not interact much with other OSes and that CET/CEST are not far
from UTC.

Concerning netfilter, if I read the doc correctly the kernel timezone is not
used by default and “using --kerneltz is highly discouraged” (in bold).

Thanks for taking an interest.

(In reply to comment #4)
> > - Define that the kernel's "local" is so backwards, that the file systems,
> >   SCSI, netfilter are just too broken to be supported that way; that we just
> >   ignore all ideas of "local" and define the use UTC and accept hickups
> >   for multi-OS boots. Sounds a bit radical, but the most appealing of all
> >   options, to just not support that kind of stupidity in 2014.
> 
> I wholeheartedly support that solution, but I may be biassed by the facts
> that I do not interact much with other OSes and that CET/CEST are not far
> from UTC.

Seems like the only sensible option. Welcome to 2014! :)

The concept of "local time" is limited to the RTC-in-local-time mode now.
Systemd will no longer set the kernel's timezone for any normal setup.
Timestamps are UTC now which should make them monotonically increasing,
not jumping backwards.