Leap second in Database system (Postgresql and SQL Server)
Here's a description of PostgreSQL's date handling I found on the pgsql mailing list from January 2012:


  As best I can tell, that document is talking about issues that are
  beyond Postgres' ken.  When you tell us a timestamp value is
  '2012-01-30 21:13:28.097017-05', that's what we store --- whether you
  meant it to be in TAI, UTC, UT1, or whatever is not our concern.
  If you then ask for that date plus one day, we're going to tell you
  '2012-01-31 21:13:28.097017-05'.  We do know about civil time zones and
  daylight savings transitions, and will adjust such answers for those,
  but not about leap seconds.  There's been very little user demand for
  leap-second-aware date arithmetic, and the difficulties with
  extrapolating such arithmetic into the future mean that we're not
  likely ever to try to support it. [emphasis mine]


As Daniel Vérité mentioned in the comments, the bug here isn't that PostgreSQL can't store leap seconds -- it can -- it's that it can't distinguish them from the following second, and can't do maths involving leap seconds.

Also, as dbafromthecold pointed out, some operating systems won't report leap seconds at all e.g. How the Windows Time service treats a leap second. Another example is Google's services, which apply a leap smear, slightly speeding up the server clocks before the leap second so as to skip over the leap second without ending up too far ahead of UTC.

So: it looks like most services are fine with a potential one-second error around leap seconds. If you need better accuracy around leap seconds, AFAICT you will need to implement your own UTC-based clock time.