I thought this might be useful:
There are three places where the timezone might be set in MySQL:
In the file "my.cnf" in the [mysqld] section
default-time-zone='+00:00'
@@global.time_zone variable
To see what value they are set to:
SELECT @@global.time_zone;
To set a value for it use either one:
SET GLOBAL time_zone = '+8:00';
SET GLOBAL time_zone = 'Europe/Helsinki';
SET @@global.time_zone = '+00:00';
(Using named timezones like 'Europe/Helsinki' means that you have to have a timezone table properly populated.)
Keep in mind that +02:00
is an offset. Europe/Berlin
is a timezone (that has two offsets) and CEST
is a clock time that corresponds to a specific offset.
@@session.time_zone variable
SELECT @@session.time_zone;
To set it use either one:
SET time_zone = 'Europe/Helsinki';
SET time_zone = "+00:00";
SET @@session.time_zone = "+00:00";
Both might return SYSTEM which means that they use the timezone set in my.cnf.
For timezone names to work, you must setup your timezone information tables need to be populated: http://dev.mysql.com/doc/refman/5.1/en/time-zone-support.html. I also mention how to populate those tables in this answer.
To get the current timezone offset as TIME
SELECT TIMEDIFF(NOW(), UTC_TIMESTAMP);
It will return 02:00:00 if your timezone is +2:00.
To get the current UNIX timestamp:
SELECT UNIX_TIMESTAMP();
SELECT UNIX_TIMESTAMP(NOW());
To get the timestamp column as a UNIX timestamp
SELECT UNIX_TIMESTAMP(`timestamp`) FROM `table_name`
To get a UTC datetime column as a UNIX timestamp
SELECT UNIX_TIMESTAMP(CONVERT_TZ(`utc_datetime`, '+00:00', @@session.time_zone)) FROM `table_name`
Note: Changing the timezone will not change the stored datetime or timestamp, but it will show a different datetime for existing timestamp columns as they are internally stored as UTC timestamps and externally displayed in the current MySQL timezone.
I made a cheatsheet here: Should MySQL have its timezone set to UTC?
Using an offset to calculate Timezone is a wrong approach, and you will always encounter problems. Time zones and daylight saving rules may change on several occasions during a year, and It's difficult to keep up with changes.
To get the system's IANA timezone in JavaScript, you should use
console.log(Intl.DateTimeFormat().resolvedOptions().timeZone)
Old compatibility information
ecma-402/1.0 says that timeZone
may be undefined if not provided to constructor. However, future draft (3.0) fixed that issue by changing to system default timezone.
In this version of the ECMAScript Internationalization API, the
timeZone
property will remain undefined if no timeZone
property was
provided in the options object provided to the Intl.DateTimeFormat
constructor. However, applications should not rely on this, as future
versions may return a String value identifying the host environment’s
current time zone instead.
in ecma-402/3.0 which is still in a draft it changed to
In this version of the ECMAScript 2015 Internationalization API, the
timeZone
property will be the name of the default time zone if no
timeZone
property was provided in the options object provided to the
Intl.DateTimeFormat
constructor. The previous version left the
timeZone
property undefined in this case.
Best Answer
I just found a free zip database that includes time offset and participation in DST. I do like Erik J's answer, as it would help me choose the actual time zone as opposed to just the offset (because you never can be completely sure on the rules), but I think I might start with this, and have it try to find the best time zone match based on offset/dst configuration. I think I may try to set up a simple version of Development 4.0's answer to check against what I get from the zip info as a sanity test. It's definitely not as simple as I'd hope, but a combination should get me at least 90% sure of a user's time zone.