How do I set timezone to UTC-8
I need to set my timezone to UTC -8, I only see options to set to PST or GMT-8. Is there a way to make it show as UTC-8?
I am running RHEL6.
$ date
Sat Feb 23 01:41:41 UTC 2019
linux timezone
add a comment |
I need to set my timezone to UTC -8, I only see options to set to PST or GMT-8. Is there a way to make it show as UTC-8?
I am running RHEL6.
$ date
Sat Feb 23 01:41:41 UTC 2019
linux timezone
1
aren't UTC and GMT the same?
– Jeff Schaller
Feb 23 at 2:33
Technically, they're not the same, per that link. UTC is a standard, rather than a timezone, so shouldn't actually be an option for the timezone. I do recall a disagreement decades ago, in which UTC supported leap seconds and GMT didn't, which made them be different by a few seconds, but that's been resolved asTZ=GMT date; TZ=UTC date
reports the same time twice, apart from calling one GMT and one UTC.
– Ed Grimm
Feb 23 at 2:39
add a comment |
I need to set my timezone to UTC -8, I only see options to set to PST or GMT-8. Is there a way to make it show as UTC-8?
I am running RHEL6.
$ date
Sat Feb 23 01:41:41 UTC 2019
linux timezone
I need to set my timezone to UTC -8, I only see options to set to PST or GMT-8. Is there a way to make it show as UTC-8?
I am running RHEL6.
$ date
Sat Feb 23 01:41:41 UTC 2019
linux timezone
linux timezone
edited Feb 23 at 2:27
Jeff Schaller
43.4k1160140
43.4k1160140
asked Feb 23 at 1:52
SpruceTipsSpruceTips
192214
192214
1
aren't UTC and GMT the same?
– Jeff Schaller
Feb 23 at 2:33
Technically, they're not the same, per that link. UTC is a standard, rather than a timezone, so shouldn't actually be an option for the timezone. I do recall a disagreement decades ago, in which UTC supported leap seconds and GMT didn't, which made them be different by a few seconds, but that's been resolved asTZ=GMT date; TZ=UTC date
reports the same time twice, apart from calling one GMT and one UTC.
– Ed Grimm
Feb 23 at 2:39
add a comment |
1
aren't UTC and GMT the same?
– Jeff Schaller
Feb 23 at 2:33
Technically, they're not the same, per that link. UTC is a standard, rather than a timezone, so shouldn't actually be an option for the timezone. I do recall a disagreement decades ago, in which UTC supported leap seconds and GMT didn't, which made them be different by a few seconds, but that's been resolved asTZ=GMT date; TZ=UTC date
reports the same time twice, apart from calling one GMT and one UTC.
– Ed Grimm
Feb 23 at 2:39
1
1
aren't UTC and GMT the same?
– Jeff Schaller
Feb 23 at 2:33
aren't UTC and GMT the same?
– Jeff Schaller
Feb 23 at 2:33
Technically, they're not the same, per that link. UTC is a standard, rather than a timezone, so shouldn't actually be an option for the timezone. I do recall a disagreement decades ago, in which UTC supported leap seconds and GMT didn't, which made them be different by a few seconds, but that's been resolved as
TZ=GMT date; TZ=UTC date
reports the same time twice, apart from calling one GMT and one UTC.– Ed Grimm
Feb 23 at 2:39
Technically, they're not the same, per that link. UTC is a standard, rather than a timezone, so shouldn't actually be an option for the timezone. I do recall a disagreement decades ago, in which UTC supported leap seconds and GMT didn't, which made them be different by a few seconds, but that's been resolved as
TZ=GMT date; TZ=UTC date
reports the same time twice, apart from calling one GMT and one UTC.– Ed Grimm
Feb 23 at 2:39
add a comment |
1 Answer
1
active
oldest
votes
You haven't said where you're setting this time zone, but you can invent any zone name you like in the TZ
environment variable:
$ TZ='<UTC-8>+8' date
Fri Feb 22 19:25:36 UTC-8 2019
The +8
is because POSIX, stupidly, requires the offsets to be backwards (increasing westwards); the part in <...>
is the displayed name and can be any single word. If it were purely alphabetic, the angle brackets wouldn't be required, but the -
and 8
require them.
$ TZ='<yesterday>24' date
Fri Feb 22 03:30:15 yesterday 2019
$ TZ='tomorrow-24' date
Sun Feb 24 03:30:26 tomorrow 2019
If you're using a GUI or other zone-selection tool it is probably looking in /usr/share/zoneinfo
for the zone definitions included in your system. If you want another zone to show up in that list, you would need to make a suitable zoneinfo file and copy it into place. The zic
tool is used to compile zoneinfo files from the textual format, which is relatively straightforward (particularly when just modifying an existing zone to change the name).
On some systems (but not, I think, Red Hat), there is a file /etc/timezone
that globally sets the time zone as a name, and you can use that TZ
variable format in that. Other systems use only /etc/localtime
, which is conventionally a copy of one of the zoneinfo files, so you'd need to make a suitable file there too.
For per-user or -session zones, you can only use the environment variable.
If you set the zone to "UTC-8
" or some other zone that isn't specifically defined, it's treated as two things: first, a name for the zone ("UTC": whatever alphabetic string is there), and second an offset in POSIX orientation (whatever number is there). That means that TZ=UTC-8 date
will output something like
Sat Feb 23 11:50:01 UTC 2019
- that is, it reports the time in China or Western Australia, and thinks the zone is called "UTC". This behaviour is deeply confusing and annoying to track down when you make a typo. It may be the cause of the output you included in the question, but I can't tell.
This is being parsed as the traditional, mostly-obsolete, POSIX time zone format RST6RDT5,M10.3.0/00:00:00,M2.4.0/00:00:00
, which includes optional names and offsets for standard and daylight time, and dates of changeover between the two. There are a lot of drawbacks to this approach for any non-trivial zone, and it doesn't track historical changes of definition in the way that the zone files do.
The "correct" thing to do is to use either the America/Los_Angeles zone, which displays as PST, or Etc/GMT+8 if you can't use the name or don't want daylight savings changes. GMT+8 displays the offset as "-08" with no textual label. Sometimes the supposedly-correct thing isn't good enough, and in that case one of the above should be ok.
Great answer! But I think you could improve it by adding a reference to explain this part: POSIX requires the offsets to be backwards (increasing westwards), as your answer only states that without explaining it further.
– filbranden
Feb 23 at 6:20
1
The offset is defined as "the value added to the local time to arrive at Coordinated Universal Time". There are also some concrete examples in thetzset
documentation.
– Michael Homer
Feb 23 at 6:33
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f502439%2fhow-do-i-set-timezone-to-utc-8%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
You haven't said where you're setting this time zone, but you can invent any zone name you like in the TZ
environment variable:
$ TZ='<UTC-8>+8' date
Fri Feb 22 19:25:36 UTC-8 2019
The +8
is because POSIX, stupidly, requires the offsets to be backwards (increasing westwards); the part in <...>
is the displayed name and can be any single word. If it were purely alphabetic, the angle brackets wouldn't be required, but the -
and 8
require them.
$ TZ='<yesterday>24' date
Fri Feb 22 03:30:15 yesterday 2019
$ TZ='tomorrow-24' date
Sun Feb 24 03:30:26 tomorrow 2019
If you're using a GUI or other zone-selection tool it is probably looking in /usr/share/zoneinfo
for the zone definitions included in your system. If you want another zone to show up in that list, you would need to make a suitable zoneinfo file and copy it into place. The zic
tool is used to compile zoneinfo files from the textual format, which is relatively straightforward (particularly when just modifying an existing zone to change the name).
On some systems (but not, I think, Red Hat), there is a file /etc/timezone
that globally sets the time zone as a name, and you can use that TZ
variable format in that. Other systems use only /etc/localtime
, which is conventionally a copy of one of the zoneinfo files, so you'd need to make a suitable file there too.
For per-user or -session zones, you can only use the environment variable.
If you set the zone to "UTC-8
" or some other zone that isn't specifically defined, it's treated as two things: first, a name for the zone ("UTC": whatever alphabetic string is there), and second an offset in POSIX orientation (whatever number is there). That means that TZ=UTC-8 date
will output something like
Sat Feb 23 11:50:01 UTC 2019
- that is, it reports the time in China or Western Australia, and thinks the zone is called "UTC". This behaviour is deeply confusing and annoying to track down when you make a typo. It may be the cause of the output you included in the question, but I can't tell.
This is being parsed as the traditional, mostly-obsolete, POSIX time zone format RST6RDT5,M10.3.0/00:00:00,M2.4.0/00:00:00
, which includes optional names and offsets for standard and daylight time, and dates of changeover between the two. There are a lot of drawbacks to this approach for any non-trivial zone, and it doesn't track historical changes of definition in the way that the zone files do.
The "correct" thing to do is to use either the America/Los_Angeles zone, which displays as PST, or Etc/GMT+8 if you can't use the name or don't want daylight savings changes. GMT+8 displays the offset as "-08" with no textual label. Sometimes the supposedly-correct thing isn't good enough, and in that case one of the above should be ok.
Great answer! But I think you could improve it by adding a reference to explain this part: POSIX requires the offsets to be backwards (increasing westwards), as your answer only states that without explaining it further.
– filbranden
Feb 23 at 6:20
1
The offset is defined as "the value added to the local time to arrive at Coordinated Universal Time". There are also some concrete examples in thetzset
documentation.
– Michael Homer
Feb 23 at 6:33
add a comment |
You haven't said where you're setting this time zone, but you can invent any zone name you like in the TZ
environment variable:
$ TZ='<UTC-8>+8' date
Fri Feb 22 19:25:36 UTC-8 2019
The +8
is because POSIX, stupidly, requires the offsets to be backwards (increasing westwards); the part in <...>
is the displayed name and can be any single word. If it were purely alphabetic, the angle brackets wouldn't be required, but the -
and 8
require them.
$ TZ='<yesterday>24' date
Fri Feb 22 03:30:15 yesterday 2019
$ TZ='tomorrow-24' date
Sun Feb 24 03:30:26 tomorrow 2019
If you're using a GUI or other zone-selection tool it is probably looking in /usr/share/zoneinfo
for the zone definitions included in your system. If you want another zone to show up in that list, you would need to make a suitable zoneinfo file and copy it into place. The zic
tool is used to compile zoneinfo files from the textual format, which is relatively straightforward (particularly when just modifying an existing zone to change the name).
On some systems (but not, I think, Red Hat), there is a file /etc/timezone
that globally sets the time zone as a name, and you can use that TZ
variable format in that. Other systems use only /etc/localtime
, which is conventionally a copy of one of the zoneinfo files, so you'd need to make a suitable file there too.
For per-user or -session zones, you can only use the environment variable.
If you set the zone to "UTC-8
" or some other zone that isn't specifically defined, it's treated as two things: first, a name for the zone ("UTC": whatever alphabetic string is there), and second an offset in POSIX orientation (whatever number is there). That means that TZ=UTC-8 date
will output something like
Sat Feb 23 11:50:01 UTC 2019
- that is, it reports the time in China or Western Australia, and thinks the zone is called "UTC". This behaviour is deeply confusing and annoying to track down when you make a typo. It may be the cause of the output you included in the question, but I can't tell.
This is being parsed as the traditional, mostly-obsolete, POSIX time zone format RST6RDT5,M10.3.0/00:00:00,M2.4.0/00:00:00
, which includes optional names and offsets for standard and daylight time, and dates of changeover between the two. There are a lot of drawbacks to this approach for any non-trivial zone, and it doesn't track historical changes of definition in the way that the zone files do.
The "correct" thing to do is to use either the America/Los_Angeles zone, which displays as PST, or Etc/GMT+8 if you can't use the name or don't want daylight savings changes. GMT+8 displays the offset as "-08" with no textual label. Sometimes the supposedly-correct thing isn't good enough, and in that case one of the above should be ok.
Great answer! But I think you could improve it by adding a reference to explain this part: POSIX requires the offsets to be backwards (increasing westwards), as your answer only states that without explaining it further.
– filbranden
Feb 23 at 6:20
1
The offset is defined as "the value added to the local time to arrive at Coordinated Universal Time". There are also some concrete examples in thetzset
documentation.
– Michael Homer
Feb 23 at 6:33
add a comment |
You haven't said where you're setting this time zone, but you can invent any zone name you like in the TZ
environment variable:
$ TZ='<UTC-8>+8' date
Fri Feb 22 19:25:36 UTC-8 2019
The +8
is because POSIX, stupidly, requires the offsets to be backwards (increasing westwards); the part in <...>
is the displayed name and can be any single word. If it were purely alphabetic, the angle brackets wouldn't be required, but the -
and 8
require them.
$ TZ='<yesterday>24' date
Fri Feb 22 03:30:15 yesterday 2019
$ TZ='tomorrow-24' date
Sun Feb 24 03:30:26 tomorrow 2019
If you're using a GUI or other zone-selection tool it is probably looking in /usr/share/zoneinfo
for the zone definitions included in your system. If you want another zone to show up in that list, you would need to make a suitable zoneinfo file and copy it into place. The zic
tool is used to compile zoneinfo files from the textual format, which is relatively straightforward (particularly when just modifying an existing zone to change the name).
On some systems (but not, I think, Red Hat), there is a file /etc/timezone
that globally sets the time zone as a name, and you can use that TZ
variable format in that. Other systems use only /etc/localtime
, which is conventionally a copy of one of the zoneinfo files, so you'd need to make a suitable file there too.
For per-user or -session zones, you can only use the environment variable.
If you set the zone to "UTC-8
" or some other zone that isn't specifically defined, it's treated as two things: first, a name for the zone ("UTC": whatever alphabetic string is there), and second an offset in POSIX orientation (whatever number is there). That means that TZ=UTC-8 date
will output something like
Sat Feb 23 11:50:01 UTC 2019
- that is, it reports the time in China or Western Australia, and thinks the zone is called "UTC". This behaviour is deeply confusing and annoying to track down when you make a typo. It may be the cause of the output you included in the question, but I can't tell.
This is being parsed as the traditional, mostly-obsolete, POSIX time zone format RST6RDT5,M10.3.0/00:00:00,M2.4.0/00:00:00
, which includes optional names and offsets for standard and daylight time, and dates of changeover between the two. There are a lot of drawbacks to this approach for any non-trivial zone, and it doesn't track historical changes of definition in the way that the zone files do.
The "correct" thing to do is to use either the America/Los_Angeles zone, which displays as PST, or Etc/GMT+8 if you can't use the name or don't want daylight savings changes. GMT+8 displays the offset as "-08" with no textual label. Sometimes the supposedly-correct thing isn't good enough, and in that case one of the above should be ok.
You haven't said where you're setting this time zone, but you can invent any zone name you like in the TZ
environment variable:
$ TZ='<UTC-8>+8' date
Fri Feb 22 19:25:36 UTC-8 2019
The +8
is because POSIX, stupidly, requires the offsets to be backwards (increasing westwards); the part in <...>
is the displayed name and can be any single word. If it were purely alphabetic, the angle brackets wouldn't be required, but the -
and 8
require them.
$ TZ='<yesterday>24' date
Fri Feb 22 03:30:15 yesterday 2019
$ TZ='tomorrow-24' date
Sun Feb 24 03:30:26 tomorrow 2019
If you're using a GUI or other zone-selection tool it is probably looking in /usr/share/zoneinfo
for the zone definitions included in your system. If you want another zone to show up in that list, you would need to make a suitable zoneinfo file and copy it into place. The zic
tool is used to compile zoneinfo files from the textual format, which is relatively straightforward (particularly when just modifying an existing zone to change the name).
On some systems (but not, I think, Red Hat), there is a file /etc/timezone
that globally sets the time zone as a name, and you can use that TZ
variable format in that. Other systems use only /etc/localtime
, which is conventionally a copy of one of the zoneinfo files, so you'd need to make a suitable file there too.
For per-user or -session zones, you can only use the environment variable.
If you set the zone to "UTC-8
" or some other zone that isn't specifically defined, it's treated as two things: first, a name for the zone ("UTC": whatever alphabetic string is there), and second an offset in POSIX orientation (whatever number is there). That means that TZ=UTC-8 date
will output something like
Sat Feb 23 11:50:01 UTC 2019
- that is, it reports the time in China or Western Australia, and thinks the zone is called "UTC". This behaviour is deeply confusing and annoying to track down when you make a typo. It may be the cause of the output you included in the question, but I can't tell.
This is being parsed as the traditional, mostly-obsolete, POSIX time zone format RST6RDT5,M10.3.0/00:00:00,M2.4.0/00:00:00
, which includes optional names and offsets for standard and daylight time, and dates of changeover between the two. There are a lot of drawbacks to this approach for any non-trivial zone, and it doesn't track historical changes of definition in the way that the zone files do.
The "correct" thing to do is to use either the America/Los_Angeles zone, which displays as PST, or Etc/GMT+8 if you can't use the name or don't want daylight savings changes. GMT+8 displays the offset as "-08" with no textual label. Sometimes the supposedly-correct thing isn't good enough, and in that case one of the above should be ok.
edited Feb 23 at 6:31
answered Feb 23 at 4:06
Michael HomerMichael Homer
49.8k8134174
49.8k8134174
Great answer! But I think you could improve it by adding a reference to explain this part: POSIX requires the offsets to be backwards (increasing westwards), as your answer only states that without explaining it further.
– filbranden
Feb 23 at 6:20
1
The offset is defined as "the value added to the local time to arrive at Coordinated Universal Time". There are also some concrete examples in thetzset
documentation.
– Michael Homer
Feb 23 at 6:33
add a comment |
Great answer! But I think you could improve it by adding a reference to explain this part: POSIX requires the offsets to be backwards (increasing westwards), as your answer only states that without explaining it further.
– filbranden
Feb 23 at 6:20
1
The offset is defined as "the value added to the local time to arrive at Coordinated Universal Time". There are also some concrete examples in thetzset
documentation.
– Michael Homer
Feb 23 at 6:33
Great answer! But I think you could improve it by adding a reference to explain this part: POSIX requires the offsets to be backwards (increasing westwards), as your answer only states that without explaining it further.
– filbranden
Feb 23 at 6:20
Great answer! But I think you could improve it by adding a reference to explain this part: POSIX requires the offsets to be backwards (increasing westwards), as your answer only states that without explaining it further.
– filbranden
Feb 23 at 6:20
1
1
The offset is defined as "the value added to the local time to arrive at Coordinated Universal Time". There are also some concrete examples in the
tzset
documentation.– Michael Homer
Feb 23 at 6:33
The offset is defined as "the value added to the local time to arrive at Coordinated Universal Time". There are also some concrete examples in the
tzset
documentation.– Michael Homer
Feb 23 at 6:33
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f502439%2fhow-do-i-set-timezone-to-utc-8%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
aren't UTC and GMT the same?
– Jeff Schaller
Feb 23 at 2:33
Technically, they're not the same, per that link. UTC is a standard, rather than a timezone, so shouldn't actually be an option for the timezone. I do recall a disagreement decades ago, in which UTC supported leap seconds and GMT didn't, which made them be different by a few seconds, but that's been resolved as
TZ=GMT date; TZ=UTC date
reports the same time twice, apart from calling one GMT and one UTC.– Ed Grimm
Feb 23 at 2:39