This night will be longer because of leap second: https://en.wikipedia.org/wiki/Leap_second
My impact will be minimal in my case, I don't even know if I will recive some weird data like 20150630 23:59:60. But I have monitoring systems from both windows, linux and other systems. In worst case, I will lose one second of data.
I tested conversion of this weird data in postgresql and SQL Server. These are my results:
This select in Postgresql:
SELECT '20150630 23:59:60.001 UTC'::timestamptz;
Is returning: 2015-07-01 02:00:00.001+02
I have the same result with:
SELECT '20150701 00:00:00.001 UTC'::timestamptz;
I think this can be dangerous in critical systems, because, if this data is handled by clients, data can be stored in the wrong order, adding a second to a legitimate data.
In sql server if I try:
SELECT CAST('20150630 23:59:60' AS datetime)
It give me a conversion error. So it is not possible, in sql server, to store this data.
One gives me an error, the other just add a second. I don't like both, because it is impossible to store events in the leap second.
Both are recent systems. SQL server is 2014 on a window 2012 machine. Postgresql is 9.3 on redhat machine (not so update, I think a 6.2).
What if someone ask me to store this data? I read this and some workarounds: https://stackoverflow.com/questions/19751115/leap-second-handling-in-database
Has anyone faced this as a problem? I mean, this is just a theoretical question in my case, not a real problem (so don't waste time if you don't like theoretical questions)
EDIT: Tested in Oracle 11.2, error is returned:
ORA-01852: seconds must be between 0 and 59 01852. 00000 - "seconds must be between 0 and 59"