My system (Gnome 3 on Debian Testing) is confused about the current time. When I run date the time is showing correctly but some applications are an hour behind the times. For instance, when I add an event to Gnome Calendar the event time shown in the calendar appointments will be the time I entered minus one hour.

I've found out what the issue is but don't know how to solve it:

$ date ; TZ=GMT date ; TZ=BST date
Sun 30 Apr 11:25:37 BST 2017
Sun 30 Apr 10:25:37 GMT 2017
Sun 30 Apr 10:25:37 BST 2017

The first two lines of the output are correct, the third is an hour behind. What I can't understand is why the BST time zone appears to be an hour behind while at the same time the current time is correct - and using BST.

This may also be relevant:

$ timedatectl status
      Local time: Sun 2017-04-30 11:33:07 BST
  Universal time: Sun 2017-04-30 10:33:07 UTC
        RTC time: Sun 2017-04-30 10:33:07
       Time zone: Europe/London (BST, +0100)
 Network time on: yes
NTP synchronized: yes
 RTC in local TZ: no

Edit Output of zdump /etc/localtime:

$ zdump /etc/localtime
/etc/localtime  Sun Apr 30 12:22:53 2017 BST

$ date ; TZ=GMT date ; TZ=BST date
Sun 30 Apr 12:22:53 BST 2017
Sun 30 Apr 11:22:53 GMT 2017
Sun 30 Apr 11:22:53 BST 2017
  • Please add the output of zdump /etc/localtime Commented Apr 30, 2017 at 11:10
  • Done (see edit). The time shown by the output is correct but TZ=BST date is an hour behind.
    – rkhff
    Commented Apr 30, 2017 at 11:27
  • 1
    I wonder if BST is a correct value for TZ. What happens if you do TZ=AAA date? (i.e., use a timezone that does not exist)
    – Kusalananda
    Commented Apr 30, 2017 at 11:47
  • Good point. It outputs the current time, in BST: $ tz=AAA returns date Sun 30 Apr 13:08:58 BST 2017
    – rkhff
    Commented Apr 30, 2017 at 12:11
  • @Kusalananda From the top of my head BST is British Standard Time and does exist, confirmed by the output of zdump. Can the OP be hitting some obscure systemd bug? Commented Apr 30, 2017 at 15:25

3 Answers 3


BST is not recognized as a timezone name. It's used as an abbreviation in output, but you can't use it to designate a timezone. Most programs don't check timezone names and silently default to GMT if the timezone name is not recognized.

Abbreviations like BST, CET, EST, etc. are not always well-defined and sometimes ambiguous (is it North American or Australian Eastern standard time?). They are meaningful only in a given region, whereas the timezone configuration is typically intended for worlwide use. Furthermore an abbreviation like BST doesn't actually designate a timezone, but only the time it is in a certain timezone for part of the year (Britain while summer time is in effect). So you should use unambiguous designations, most of which follow the pattern continent/city. On typical Linux systems, and I think on many other Unix variants as well, you can see which abbreviations are available by looking in the directory /usr/share/zoneinfo.

So instead of using GMT in winter and BST in summer, use Europe/London.

  • Europe/London is what I was using (see output of timedatectl status in my question). Even with TZ=':Europe/London'; export TZ in my ~/.profile file the issue still exists.
    – rkhff
    Commented May 3, 2017 at 11:58

As @Gilles said, that BST is something that is output upon date/date +%Z, to tell users that it's a British Summer Time date (so GMT+1) not something that defines a timezone, not something that you can use for $TZ.

That BST is significant to British users. When a British user sees 14:00 BST, they know the timestamp refers to 14:00 summer time in mainland Britain (so 13:00 UTC). The use of those 3-4 letter codes is widespread in Britain, the US and some other English speaking countries, so show up in the default output of date there (in en_GB.UTF-8 locales for instance). On the other hand, most French users will have no idea what 14:00 CEST means (even though CEST refers to Central European Summer Time, the GMT+2 that applies in summer in France), so you'd notice that when dates specify the time zone, they rather include the UTC offset than CET/CEST there (like mardi 2 mai 2017, 13:34:09 (UTC+0200)).

The $TZ variable is not meant to contain those 3-4 letter codes. It contains something that defines/specifies the timezone, the region you're in. Applications use it to know the offset with UTC at any point in time, when to switch between Winter and Summer time and what the code (if any) for the Winter and Summer time would be displayed to the user (for those users for whom it's significant).

For that, you can either set TZ to some system-defined timezone specification. Like TZ=:Europe/London (though many systems also accept TZ=Europe/London as well), or have TZ contain the full rules (though those rules are limited).

For instance, If I use TZ=:Europe/London on my system, then the rules will be read from /usr/share/zoneinfo/Europe/London.

That file will specify for instance that since 1996, the offset from UTC is 0 from the last Sunday in October at 2am UTC to the last Sunday in March (with name GMT for "Greenwich Mean Time") and 1 other wise (with name BST for "British Summer Time"), while for 1970 (0 Unix time) to 1972, it was 1 all year round with name BST for "British Standard Time".

You can see already that it makes no sense to use BST as a timezone specification. First, it has meant different things at different points in time, and even if we only consider the current epoch, it's only a code for the summer time, so can't be used to as a timezone specification for the whole year.

Now, you can also have TZ contain the full rules. For instance for the "British Standard (not Summer) Time" of the early 70s, you can use the simplest form of specification:


That specifies a timezone that is always 1 hour East of UTC and for which date +%Z always returns BST. That timezone is correct for mainland Britain for the early 70s and for summer time since 1972, but not for Winter time since 1972 (and we can't tell for the future).

Or you can use the full specification for the current rules:


That says that there are two periods in the year, one for which the name is GMT with offset 0, and one BST with offset 1 (implied as 0+1 above when not specified), where the switch from one to the other is on the last (5) Sunday (0) of March (3) at 1:00:00 UTC and back on the last sunday of October at 2:00.

Again, that TZ works from 1996 to now, but not necessarily otherwise. For instance, for 1970-01-01 00:00:00 UTC (0 Unix epoch time, when the local time was 1:00:00 BST (British Standard Time) in London):

$ TZ=:Europe/London date -d @0
Thu  1 Jan 01:00:00 BST 1970
$ TZ=GMT0BST,M3.5.0/1:00:00,M10.5.0/2:00:00 date -d @0
Thu  1 Jan 00:00:00 GMT 1970

Per POSIX, the behaviour for

  • TZ=BST-1 is well defined (as described above)
  • TZ=BST (or TZ=GMT/TZ=UTC/TZ=Europe/London) is unspecified.
  • TZ=:BST/TZ=:Europe/London is implementation defined. That is systems are meant to support it and document what that does though POSIX doesn't tell us what's that done.

In the third case above, on GNU systems (and I believe most other Unix-like systems), when TZ starts with a :, what followed is taken as a path to a timezone definition file. In the case of GNU system, that's the case as well when : is omitted (even if the value forms a valid timezone specification like UTC0, but generally there shouldn't exist such files, though I can see some exceptions on my system which makes it a non-POSIX system (for instance TZ=CST6CDT date -d 1943-01-01 +%Z outputs CWT instead of CST because there's a /usr/share/zoneinfo/CST6CDT file1 that defines a war time for that period)).

That path is generally a relative path, in which case it's relative to $TZDIR (or some default like /usr/share/zoneinfo when $TZDIR is unset as is generally the case). For security reasons, $TZDIR, absolute path or relative paths with .. components are ignored in privilege escalation contexts (like in setuid contexts).

So typically, on a GNU system, a TZ=:BST, same as TZ=BST will typically look for a /usr/share/zoneinfo/BST file. If not found (as would be the case, as BST can't possibly identify a timezone definition), it will typically assume UTC time and a timezone name (as in date +%Z output) of BST.

1Those CST6CDT like WET, CET, MET... are remnants from another time. In late 1993, the TZ database (as now maintained by IANA) changed from using adhoc (and most often ambiguous) names (like MET, GB-Eire, WET) to Area/City where the city is the most populated city (at the time of release) where the zone applies (Area being large areas like continent/ocean). For mainland Britain, where you used to use GB-Eire (not WET), you now (since 1993) use Europe/London. GB-Eire (like WET) are still available for backward compatibility (GB-Eire now links to Europe/London, while WET is defined as a Zone using UTC in Winter and the EU Rules for DST (Britain has only been following the EU rules since 1996 and with the UK now leaving the EU, nobody can say what the future holds)) but should not be used now in new deployments.


Complementing Gilles answer; I am on the same time zone as the OP. Western European Time aka WET it is the official denomination; if memory does not fail me it was included for Portugal in the Unix timezones around 1996.


European Time (WET, UTC±00:00) is a time zone covering parts of western and northwestern Europe.

The following countries and regions use WET in winter months:
- Canary Islands, > since 1946 (rest of Spain is CET, UTC+1) - Faroe Islands, since 1908
- North Eastern Greenland (Danmarkshavn and surrounding area)
- Iceland, since 1968
- Portugal, since 1912 with pauses (except Azores, UTC−1)[1]
- Madeira Islands, since 1912 with pauses[2]
- Ireland, since 1916 (legally known as Greenwich Mean Time) except between 1968 and 1971
- United Kingdom and Crown dependencies, since 1847 in England, Scotland, Wales, the Channel Islands, and the Isle of Man, and since 1916 in Northern Ireland (legally known as Greenwich Mean Time), with pauses

In the United Kingdom, from 1940 to 1945 British Summer Time (BST=CET) was used in winters, and from 1941 to 1945 and again in 1947, British Double Summer Time (BDST=CEST) was used in summers. Between 18 February 1968 and 31 October 1971, BST was used all year round.

All the above countries except Iceland implement daylight saving time in summer, switching to Western European Summer Time (WEST, UTC+1), which is one hour ahead of WET. WEST is called British Summer Time in the UK and is officially known as Irish Standard Time in Ireland.

While the official denomination for the summer time is WEST (Western European Summer Time), WETis used for TZ, and takes in account summer time/DST, advancing one hour.

'Europe/London' might be nowadays a better choice, however knowing the WET shorthand is still useful in some situations.


So, to compare results with your initial test:

$date ; TZ=GMT date ; TZ=WET date
Mon May  1 09:36:10 WEST 2017
Mon May  1 08:36:10 GMT 2017
Mon May  1 09:36:10 WEST 2017
  • Anedoctally, I still remember patching up timezone files in Ultrix when we changed for WET in 1996, and again fixing them up again for DST when summer arrived. Commented May 1, 2017 at 8:11
  • 1
    I'd use TZ=GMT0, that is define a zone with 0 offset to UTC called GMT all year round. In TZ=GMT, since the offset is not specified, it's going to be system-dependant. For instance, Microsoft systems confusingly call the "greenwich" zone, a zone that is on UTC in Winter and UTC+1 in summer. Commented May 1, 2017 at 9:30
  • @StéphaneChazelas I have not setup it explicitly with WET actually (as it is now), Europe/Lisbon done by FreeBSD default install Commented May 1, 2017 at 10:52
  • 1
    All great answers - I've learned a lot about time zones! This answer solved the issue for me though. After adding TZ='WET'; export TZ to my ~/.profile file and logging out/in everything works as it should. (Setting TZ to 'Europe/London' would still show BST when running date).
    – rkhff
    Commented May 2, 2017 at 0:03
  • 1
    Using TZ=WET indeed didn't solve my issue after all - the event times in Gnome's date thingie are an hour behind again. Using TZ=:Europe/London has the same effect (as shows by the output of timedatectl status in my original question). I'll keep trying different options.
    – rkhff
    Commented May 3, 2017 at 11:51

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .