I'm facing a strange behavior of date command when using time zone offset on Solaris.

>echo $TZ
Wed Mar 31 11:41:45 MEST 2021
>TZ=MET+24 date
Tue Mar 30 09:42:06 MET 2021
>TZ=MEST+24 date
Tue Mar 30 09:42:52 MEST 2021

Why date output is showing MEST when TZ is set to MET and how is TZ+24 is showing 26 hours offset instead of 24 in both timezones.


2 Answers 2


So, you are looking to understand why this (simplified) is happening:

$ TZ=MET date; TZ=MET+0 date
Tue 01 Jun 2021 06:00:00 AM MEST
Tue 01 Jun 2021 04:00:00 AM MET

That is: there are two hours difference between MET and MET+0.

The simplest of ways to debug this issue is to add a '+%z' format. That will print the offset that date is using to print the result and could help to debug where is the problem.

$ TZ=MET date "+%c %z"; TZ=MET+0 date "+%c %z"
Wed 31 Mar 2021 06:11:16 PM MEST +0200
Wed 31 Mar 2021 04:11:16 PM MET +0000

That shows that date is printing the results at -2 offset and at +0 offset.

The question is then: Why?

Maybe because the first format of TZ is std offset (something similar to TAG-03 POSIX reference) in which the TAG of the standard zone is defined and an optional offset for such tag is given. If missing, the offset is assumed to be +0.

So, we are setting the name to MET and the offset to +0.


$ TZ=MET date "+%c %z"; TZ=METX+7:30 date "+%c %z"
Wed 31 Mar 2021 06:19:00 PM MEST +0200
Wed 31 Mar 2021 08:49:00 AM METX -0730

The TAG is simple: it is the name that will be printed for the time zone.

The offset used for such tag is the one given: -7:30 (no questions asked).

It should be clear for you that there is no such METX tag anywhere and furthermore that there is no such offset of 7:30 at that tag.

That explains why a MET+24 printed a zone time with the tag MET and an offset of +0 in yesterday (equivalent to +24, try +12 if you wish).

Correct TZ

We could test a TZ that says that standard time is 7 hours and that summer time is 9 hours: MET-7MEST-9. To test we need faketime (need to be compiled for Solaris) which prints:

$ # In January (no DST):
$ faketime "1/1/21 12:00" bash -c 'date -u; TZ=MET date "+%c %z"'; \
  faketime "1/1/21 12:00" bash -c 'TZ=MET-7MEST-9  date "+%c %z"'

Fri 01 Jan 2021 04:00:00 PM UTC
Fri 01 Jan 2021 05:00:00 PM MET +0100
Fri 01 Jan 2021 11:00:00 PM MET +0700

$ # In June (DST in effect)
$ faketime "6/1/21 12:00" bash -c 'date -u; TZ=MET date "+%c %z"'; \
  faketime "6/1/21 12:00" bash -c 'TZ=MET-7MEST-9  date "+%c %z"'

Tue 01 Jun 2021 04:00:00 PM UTC
Tue 01 Jun 2021 06:00:00 PM MEST +0200
Wed 02 Jun 2021 01:00:00 AM MEST +0900

That is just to confirm our analysis. The TZ value could be reduced to MET-7MEST as the default effect of the DST is to increase the time on 1 hour. And, as the real UTC offset of MET is +1, we can settle on saying that TZ should be: MET-1MEST. If the dst tag is missing (MET-1) the dst offset is not applied.

For your goal of setting time to yesterday (+24 hours), you should use:



  • Long live knowledge, everything is clear, thank you !
    – storm
    Apr 1, 2021 at 8:29

MET alone apparently refers to Middle European Time (= UTC +1 hour), which transitioned to Daylight Saving Time version (UTC +2 hours) on last Sunday of March (March 28 this year), and the DST version is known as Middle European Summer Time. So effectively "MET" is interpreted as a shorthand for "MET-1MEST". The total UTC difference of 2 hours comes from 1 hour of timezone-based UTC offset and 1 hour of DST offset.

From that, I can also see that the base UTC time when you entered those commands was about 09:42 UTC.

But when you specify "MET+24", that is "some strange timezone that uses the identifier MET and converts to UTC so that (local time) + 24 h = UTC." For converting UTC to local time, that formula is applied in reverse, so "local time in MET+24 timezone" is UTC - 24 hours, or UTC time exactly one day in the past.

And since there is no DST rule for "MET+24", no DST correction gets applied.


You must log in to answer this question.

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