Heidisql: Wrong timestamp display as date value in grid

Created on 31 Jan 2018 · 5Comments · Source: HeidiSQL/HeidiSQL

Setting "This is a UNIX timestamp column" active in Grid view options to see a UNIX timestamp as date representation.

Expected behavior

Following (unix timestamp) value is stored as BIGINT in datebase:
1098655200
GMT: Sunday, October 24, 2004 10:00:00 PM
Berlin: Monday, October 25, 2004 12:00:00 AM GMT+02:00 DST

Grid should show here:
2004-10-24 22:00:00 (GMT) or
2004-11-25 00:00:00 (Local)

Current behavior

Grid shows:
2004-10-24 23:00:00

It seems that the momentary timezone is used to display the value, and this is GMT+1 as of today (2018-01-31) in Germany, no daylight saving.
Value must be displayed according to the timezone at the specified date, which was GMT+2, daylight saving active.

Steps to reproduce

Create a BIGINT column and insert a value of 1098655200
Set "Grid view options" to "This is a UNIX timestamp column"
You'll get: 2004-10-24 23:00:00
Expected: 2004-11-25 00:00:00

Context

HeidiSQL version: 9.5.0.5196
Database system + version: MariaDB 10.2.12
Operating system: Windows 10, Timezone Europe/Berlin

bug

Source

mpaland

👍2

All 5 comments

hey @mpaland, your MariaDB is running with correct timezone Europe/Berlin?
I do not handle a lot of conversions, timestamp writes to UTC, does not it? and MySQL converts to your timezone?

I tried to reproduce but on the servers I have is without the timezones installed :(

lukinhaspm on 10 Feb 2018

@lukinhaspm it's no question of the server, it's just a question of the correct timestamp representation in HeidiSQL. A UNIX TIMESTAMP is always meant to be in seconds after 1970-01-01 00:00:00 UTC.

You can present such a timestamp strictly in UTC, which is fine, or in a certain (mostly the own) timezone. Doing that, needs the valid timezone on the timestamp date, not on the actual date.
It seems that HeidiSQL takes the actual date. I haven't looked in its code yet, so it's just a speculation.

mpaland on 11 Feb 2018

👍1

@mpaland I understand and agree!

lukinhaspm on 15 Feb 2018

I investigated this a little further. Unfortunately the solution seems not an easy one.
Problem are the complicated DST (daylight saving time) rules all over the world and even worse their continuously changing, non constant form.
To get the local time DST corrected for a certain epoch timestamp it is necessary to know the exact DST rule which was locally applied at the timestamps time.
A conversion library needs to keep track of all DST rule changes in every country over the years to calculate the offset for any point in the past.
Windows completely ignores this problem and converts always according to the _actual_ DST rule at the time of conversion.
To do it right, it's necessary to use one of the really advanced timezone/DST libraries around the net.

mpaland on 23 Jul 2018

Although most of what @mpaland has stated about needing to know the DST rule applied when creating the timestamp is technically true (If we drop daylight saving, for example, all moments recorded while it was active would "shift" to the relative non-daylight saving time), it's still possible to use the current DST rules to properly display the time for a timestamp.

1584975600 and 1585576800 are both 16:00 at Europe/Madrid, but heidisql incorrectly represents one of them (depending if we're on daylight saving time or not)

It might be possible to correctly display these cases without it being a big hassle by just checking if the resulting time should be on daylight saving time or not and applying the correct offset.

Even though it's not a perfect solution, I'd say it probably covers most use cases, and the edge cases would probably be easily spotted, its more of a small help for devs to verify something's ok than a end user reliable display anyway.