Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #264173 > unrolled thread
| Started by | gene heskett <gheskett@shentel.net> |
|---|---|
| First post | 2023-12-04 01:50 +0100 |
| Last post | 2023-12-04 11:00 +0100 |
| Articles | 20 on this page of 99 — 17 participants |
Back to article view | Back to linux.debian.user
ntpsec as server questions gene heskett <gheskett@shentel.net> - 2023-12-04 01:50 +0100
Re: ntpsec as server questions jeremy ardley <jeremy.ardley@gmail.com> - 2023-12-04 02:00 +0100
Re: ntpsec as server questions jeremy ardley <jeremy.ardley@gmail.com> - 2023-12-04 02:10 +0100
Re: ntpsec as server questions gene heskett <gheskett@shentel.net> - 2023-12-04 10:00 +0100
Re: ntpsec as server questions Pocket <pocket@columbus.rr.com> - 2023-12-04 12:00 +0100
Re: ntpsec as server questions gene heskett <gheskett@shentel.net> - 2023-12-04 12:40 +0100
Re: ntpsec as server questions Greg Wooledge <greg@wooledge.org> - 2023-12-04 13:20 +0100
Re: ntpsec as server questions gene heskett <gheskett@shentel.net> - 2023-12-04 17:00 +0100
Re: ntpsec as server questions Dan Purgert <dan@djph.net> - 2023-12-04 17:40 +0100
Re: ntpsec as server questions gene heskett <gheskett@shentel.net> - 2023-12-04 22:30 +0100
Re: ntpsec as server questions David Wright <deblis@lionunicorn.co.uk> - 2023-12-05 04:00 +0100
Re: ntpsec as server questions Greg Wooledge <greg@wooledge.org> - 2023-12-04 17:40 +0100
Re: ntpsec as server questions Max Nikulin <manikulin@gmail.com> - 2023-12-04 18:10 +0100
Re: ntpsec as server questions Greg Wooledge <greg@wooledge.org> - 2023-12-04 19:50 +0100
Re: ntpsec as server questions Max Nikulin <manikulin@gmail.com> - 2023-12-16 11:40 +0100
Re: ntpsec as server questions gene heskett <gheskett@shentel.net> - 2023-12-04 22:30 +0100
Re: ntpsec as server questions John Hasler <john@sugarbit.com> - 2023-12-04 17:40 +0100
Re: ntpsec as server questions gene heskett <gheskett@shentel.net> - 2023-12-04 22:40 +0100
Re: ntpsec as server questions Tom Furie <tom@furie.org.uk> - 2023-12-04 17:50 +0100
Re: ntpsec as server questions Greg Wooledge <greg@wooledge.org> - 2023-12-04 20:20 +0100
Re: ntpsec as server questions gene heskett <gheskett@shentel.net> - 2023-12-04 22:40 +0100
Re: ntpsec as server questions gene heskett <gheskett@shentel.net> - 2023-12-04 20:20 +0100
Re: ntpsec as server questions Greg Wooledge <greg@wooledge.org> - 2023-12-04 13:20 +0100
Re: ntpsec as server questions Pocket <pocket@columbus.rr.com> - 2023-12-04 14:00 +0100
Re: ntpsec as server questions gene heskett <gheskett@shentel.net> - 2023-12-04 21:30 +0100
Re: ntpsec as server questions Greg Wooledge <greg@wooledge.org> - 2023-12-04 21:40 +0100
Re: ntpsec as server questions David Wright <deblis@lionunicorn.co.uk> - 2023-12-04 22:50 +0100
Re: ntpsec as server questions jeremy ardley <jeremy.ardley@gmail.com> - 2023-12-05 00:50 +0100
Re: ntpsec as server questions gene heskett <gheskett@shentel.net> - 2023-12-04 21:30 +0100
Re: ntpsec as server questions Pocket <pocket@columbus.rr.com> - 2023-12-04 23:20 +0100
Re: ntpsec as server questions Max Nikulin <manikulin@gmail.com> - 2023-12-05 17:40 +0100
Re: ntpsec as server questions Pocket <pocket@columbus.rr.com> - 2023-12-05 18:10 +0100
Re: ntpsec as server questions Max Nikulin <manikulin@gmail.com> - 2023-12-06 13:30 +0100
Re: ntpsec as server questions Pocket <pocket@columbus.rr.com> - 2023-12-06 14:10 +0100
Re: ntpsec as server questions Max Nikulin <manikulin@gmail.com> - 2023-12-06 16:10 +0100
Re: ntpsec as server questions Pocket <pocket@columbus.rr.com> - 2023-12-06 16:50 +0100
Re: ntpsec as server questions Greg Wooledge <greg@wooledge.org> - 2023-12-06 17:20 +0100
Re: ntpsec as server questions Pocket <pocket@columbus.rr.com> - 2023-12-06 17:30 +0100
Re: ntpsec as server questions Greg Wooledge <greg@wooledge.org> - 2023-12-06 17:50 +0100
Re: ntpsec as server questions Curt <curty@free.fr> - 2023-12-06 17:50 +0100
Re: ntpsec as server questions gene heskett <gheskett@shentel.net> - 2023-12-05 18:30 +0100
Re: ntpsec as server questions Pocket <pocket@columbus.rr.com> - 2023-12-05 18:30 +0100
Re: ntpsec as server questions David Wright <deblis@lionunicorn.co.uk> - 2023-12-06 06:30 +0100
Re: ntpsec as server questions Max Nikulin <manikulin@gmail.com> - 2023-12-06 17:50 +0100
Re: ntpsec as server questions Pocket <pocket@columbus.rr.com> - 2023-12-06 18:10 +0100
Re: ntpsec as server questions Greg Wooledge <greg@wooledge.org> - 2023-12-06 18:30 +0100
Re: ntpsec as server questions Pocket <pocket@columbus.rr.com> - 2023-12-06 18:40 +0100
Re: ntpsec as server questions Curt <curty@free.fr> - 2023-12-06 18:50 +0100
Re: ntpsec as server questions Greg Wooledge <greg@wooledge.org> - 2023-12-06 19:00 +0100
Re: ntpsec as server questions Pocket <pocket@columbus.rr.com> - 2023-12-06 19:10 +0100
Re: ntpsec as server questions Greg Wooledge <greg@wooledge.org> - 2023-12-06 19:30 +0100
Re: ntpsec as server questions David Wright <deblis@lionunicorn.co.uk> - 2023-12-06 21:50 +0100
Re: ntpsec as server questions Pocket <pocket@columbus.rr.com> - 2023-12-07 00:20 +0100
Re: ntpsec as server questions Greg Wooledge <greg@wooledge.org> - 2023-12-07 01:20 +0100
Re: ntpsec as server questions Pocket <pocket@columbus.rr.com> - 2023-12-07 01:30 +0100
Re: ntpsec as server questions Greg Wooledge <greg@wooledge.org> - 2023-12-07 01:30 +0100
Re: ntpsec as server questions Pocket <pocket@columbus.rr.com> - 2023-12-07 01:40 +0100
Re: ntpsec as server questions Greg Wooledge <greg@wooledge.org> - 2023-12-07 01:50 +0100
Re: ntpsec as server questions Pocket <pocket@columbus.rr.com> - 2023-12-07 02:50 +0100
Re: ntpsec as server questions David Wright <deblis@lionunicorn.co.uk> - 2023-12-07 06:50 +0100
Re: ntpsec as server questions Max Nikulin <manikulin@gmail.com> - 2023-12-08 03:40 +0100
Re: ntpsec as server questions Greg Wooledge <greg@wooledge.org> - 2023-12-08 04:10 +0100
Re: ntpsec as server questions gene heskett <gheskett@shentel.net> - 2023-12-08 05:20 +0100
Re: ntpsec as server questions Greg Wooledge <greg@wooledge.org> - 2023-12-08 13:20 +0100
Re: ntpsec as server questions Greg Wooledge <greg@wooledge.org> - 2023-12-08 18:00 +0100
Re: ntpsec as server questions Max Nikulin <manikulin@gmail.com> - 2023-12-09 12:20 +0100
Re: ntpsec as server questions Greg Wooledge <greg@wooledge.org> - 2023-12-08 13:40 +0100
Re: ntpsec as server questions <tomas@tuxteam.de> - 2023-12-08 14:20 +0100
Re: ntpsec as server questions "Thomas Schmitt" <scdbackup@gmx.net> - 2023-12-08 14:40 +0100
Re: ntpsec as server questions David Wright <deblis@lionunicorn.co.uk> - 2023-12-08 18:10 +0100
Re: ntpsec as server questions David Wright <deblis@lionunicorn.co.uk> - 2023-12-06 21:30 +0100
Re: ntpsec as server questions Pocket <pocket@columbus.rr.com> - 2023-12-07 00:20 +0100
Re: ntpsec as server questions <tomas@tuxteam.de> - 2023-12-07 06:40 +0100
Re: ntpsec as server questions David Wright <deblis@lionunicorn.co.uk> - 2023-12-07 06:50 +0100
Re: ntpsec as server questions Greg Wooledge <greg@wooledge.org> - 2023-12-07 13:20 +0100
Re: ntpsec as server questions Pocket <pocket@columbus.rr.com> - 2023-12-07 14:10 +0100
Re: ntpsec as server questions John Hasler <john@sugarbit.com> - 2023-12-07 15:30 +0100
Re: ntpsec as server questions Pocket <pocket@columbus.rr.com> - 2023-12-07 15:40 +0100
Re: ntpsec as server questions David Wright <deblis@lionunicorn.co.uk> - 2023-12-07 17:00 +0100
Local time in databases (Re: ntpsec as server questions) Max Nikulin <manikulin@gmail.com> - 2023-12-07 16:40 +0100
Re: Local time in databases (Re: ntpsec as server questions) <tomas@tuxteam.de> - 2023-12-07 17:10 +0100
Re: Local time in databases (Re: ntpsec as server questions) Max Nikulin <manikulin@gmail.com> - 2023-12-08 03:20 +0100
Re: Local time in databases (Re: ntpsec as server questions) Nicholas Geovanis <nickgeovanis@gmail.com> - 2023-12-08 05:20 +0100
Re: Local time in databases (Re: ntpsec as server questions) <tomas@tuxteam.de> - 2023-12-08 05:40 +0100
Re: Local time in databases (Re: ntpsec as server questions) Max Nikulin <manikulin@gmail.com> - 2023-12-12 18:10 +0100
Re: Local time in databases David Wright <deblis@lionunicorn.co.uk> - 2023-12-17 06:20 +0100
Re: Local time in databases (Re: ntpsec as server questions) <tomas@tuxteam.de> - 2023-12-08 05:40 +0100
Re: ntpsec as server questions James Cloos <cloos@jhcloos.com> - 2023-12-06 22:30 +0100
Re: ntpsec as server questions David Wright <deblis@lionunicorn.co.uk> - 2023-12-07 06:50 +0100
Re: ntpsec as server questions David Wright <deblis@lionunicorn.co.uk> - 2023-12-05 04:00 +0100
Re: ntpsec as server questions Anssi Saari <anssi.saari@debian-user.mail.kapsi.fi> - 2023-12-04 11:10 +0100
Re: ntpsec as server questions gene heskett <gheskett@shentel.net> - 2023-12-04 12:30 +0100
Re: ntpsec as server questions <tomas@tuxteam.de> - 2023-12-04 12:50 +0100
Re: ntpsec as server questions Greg Wooledge <greg@wooledge.org> - 2023-12-04 02:00 +0100
Re: ntpsec as server questions <tomas@tuxteam.de> - 2023-12-04 06:10 +0100
Re: ntpsec as server questions Jeffrey Walton <noloader@gmail.com> - 2023-12-04 06:30 +0100
Re: ntpsec as server questions Charles Curley <charlescurley@charlescurley.com> - 2023-12-04 07:30 +0100
Re: ntpsec as server questions Jeffrey Walton <noloader@gmail.com> - 2023-12-04 08:10 +0100
Re: ntpsec as server questions gene heskett <gheskett@shentel.net> - 2023-12-04 11:00 +0100
Page 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
| From | gene heskett <gheskett@shentel.net> |
|---|---|
| Date | 2023-12-04 22:40 +0100 |
| Message-ID | <HHoPv-bbeb-5@gated-at.bofh.it> |
| In reply to | #264242 |
On 12/4/23 14:17, Greg Wooledge wrote: > On Mon, Dec 04, 2023 at 02:11:51PM -0500, gene heskett wrote: >> That leave the localtime error pretty much up to the date command, or is >> there something else screwing with this? Where ALL in this chain does >> /etc/timezone get used, which is currently set to: >> America/New_York > > ls -ld /etc/*time* > > Please. > > . as reported, its now fixed. root@mkspi:/usr/share/zoneinfo# ls -ld /etc/*time* lrwxrwxrwx 1 root root 27 Dec 4 15:22 /etc/localtime -> /usr/share/zoneinfo/EST5EDT -rw-r--r-- 1 root root 17 Dec 4 11:44 /etc/timezone Cheers, Gene Heskett. -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis
[toc] | [prev] | [next] | [standalone]
| From | gene heskett <gheskett@shentel.net> |
|---|---|
| Date | 2023-12-04 20:20 +0100 |
| Message-ID | <HHmE1-b9ua-13@gated-at.bofh.it> |
| In reply to | #264210 |
On 12/4/23 07:10, Greg Wooledge wrote: > On Mon, Dec 04, 2023 at 06:32:38AM -0500, gene heskett wrote: >> On 12/4/23 05:55, Pocket wrote: >>> ntpq -p >> I don't have that on the printer, it is running chrony. > > A quick Google search for "chrony equivalent of ntpq" gives me > <https://karloluiten.nl/chrony-status-command-ntpq-p-alternative/> > which says to use "chronyc sources" or "chronyc tracking". > Another snippet of date, it would appear that the clock is set to utc correctly. From /proc/driver/utc: rtc_time : 16:31:50 rtc_date : 2023-12-04 alrm_time : 00:00:00 alrm_date : 1999-12-16 alarm_IRQ : no alrm_pending : no update IRQ enabled : no periodic IRQ enabled : no periodic IRQ frequency : 1 max user IRQ frequency : 64 24hr : yes Which would be nominally correct for utc That leave the localtime error pretty much up to the date command, or is there something else screwing with this? Where ALL in this chain does /etc/timezone get used, which is currently set to: America/New_York Thank you. Cheers, Gene Heskett. -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis
[toc] | [prev] | [next] | [standalone]
| From | Greg Wooledge <greg@wooledge.org> |
|---|---|
| Date | 2023-12-04 13:20 +0100 |
| Message-ID | <HHg5z-b4jt-1@gated-at.bofh.it> |
| In reply to | #264202 |
On Mon, Dec 04, 2023 at 05:55:25AM -0500, Pocket wrote:
> On 12/4/23 03:58, gene heskett wrote:
> > I have this printer getting its time info from this machine's ntpsec but
> > the chrony in the printer is ignoring /etc/timezone, stuck in PST or 4
> > hours behind me when comparing the output of "date".
>
> What does /etc/localtime say?
>
> For example on my raspberrypi 4
>
> ls -hal /etc/localtime
> lrwxrwxrwx 1 root root 27 Nov 1 18:21 /etc/localtime ->
> /usr/share/zoneinfo/EST5EDT
>
> cat /etc/timezone
> America/New_York
According to <https://wiki.debian.org/TimeZoneChanges> the correct
way to set the time zone in Debian is to run "dpkg-reconfigure tzdata"
which will update both /etc/timezone *and* /etc/localtime. Of course,
since Gene's printer isn't running Debian, we can't accurately tell
him what commands to run.
But at the bare minimum, Gene should check:
ls -ld /etc/*time*
If it turns out his printer has an /etc/localtime symlink pointing
to the wrong time zone, then re-pointing it should help.
[toc] | [prev] | [next] | [standalone]
| From | Pocket <pocket@columbus.rr.com> |
|---|---|
| Date | 2023-12-04 14:00 +0100 |
| Message-ID | <HHgIh-b4x0-5@gated-at.bofh.it> |
| In reply to | #264209 |
On 12/4/23 07:17, Greg Wooledge wrote: > On Mon, Dec 04, 2023 at 05:55:25AM -0500, Pocket wrote: >> On 12/4/23 03:58, gene heskett wrote: >>> I have this printer getting its time info from this machine's ntpsec but >>> the chrony in the printer is ignoring /etc/timezone, stuck in PST or 4 >>> hours behind me when comparing the output of "date". >> What does /etc/localtime say? >> >> For example on my raspberrypi 4 >> >> ls -hal /etc/localtime >> lrwxrwxrwx 1 root root 27 Nov 1 18:21 /etc/localtime -> >> /usr/share/zoneinfo/EST5EDT >> >> cat /etc/timezone >> America/New_York > According to <https://wiki.debian.org/TimeZoneChanges> the correct > way to set the time zone in Debian is to run "dpkg-reconfigure tzdata" > which will update both /etc/timezone *and* /etc/localtime. Of course, > since Gene's printer isn't running Debian, we can't accurately tell > him what commands to run. > > But at the bare minimum, Gene should check: > > ls -ld /etc/*time* > > If it turns out his printer has an /etc/localtime symlink pointing > to the wrong time zone, then re-pointing it should help. > Which is why I posted the above. Libc uses /etc/localtime so the printer is likely to use that By doing ls -hal /etc/localtime will point that out My research has shown that /etc/timezone is a debianism and was slated to be depreciated. dpkg-reconfigure tzdata will not allow me to set the time zone to EST5EDT -- It's not easy to be me
[toc] | [prev] | [next] | [standalone]
| From | gene heskett <gheskett@shentel.net> |
|---|---|
| Date | 2023-12-04 21:30 +0100 |
| Message-ID | <HHnJL-bajD-9@gated-at.bofh.it> |
| In reply to | #264209 |
On 12/4/23 07:17, Greg Wooledge wrote: > ls -hal /etc/localtime Aha! You found it, but how do I change it? root@mkspi:/etc# cat timezone America/New_York root@mkspi:/etc# ls -hal /etc/localtime lrwxrwxrwx 1 root root 39 Jul 25 2022 /etc/localtime -> /usr/share/zoneinfo/America/Los_Angeles use mc to edit the /etc/localtime link? Surely there is better way... chasing that link down its a link to ../posixrules, and this dog is chasing its own tail, wtf? Something is AFU but what? The string as the last few bytes of posixrules looks correct at EST5EDT, and I've got a headache. there are links to links to links in that midden heap. Whoever said there lies insanity is correct/ Thanks Greg Cheers, Gene Heskett. -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis
[toc] | [prev] | [next] | [standalone]
| From | Greg Wooledge <greg@wooledge.org> |
|---|---|
| Date | 2023-12-04 21:40 +0100 |
| Message-ID | <HHnTr-basq-5@gated-at.bofh.it> |
| In reply to | #264246 |
On Mon, Dec 04, 2023 at 03:19:33PM -0500, gene heskett wrote:
> On 12/4/23 07:17, Greg Wooledge wrote:
> > ls -hal /etc/localtime
>
> Aha! You found it, but how do I change it?
> root@mkspi:/etc# cat timezone
> America/New_York
> root@mkspi:/etc# ls -hal /etc/localtime
> lrwxrwxrwx 1 root root 39 Jul 25 2022 /etc/localtime ->
> /usr/share/zoneinfo/America/Los_Angeles
It's just a symbolic link. It looks like you have the "modern" style
of zone names, so:
ln -sf /usr/share/zoneinfo/America/New_York /etc/localtime
> use mc to edit the /etc/localtime link? Surely there is better way...
I don't know how mc works. I've never used it. If that can change the
target of a symlink, similar to running "ln -sf", then you may use it.
> The string as the last few
> bytes of posixrules looks correct at EST5EDT, and I've got a headache.
> there are links to links to links in that midden heap.
I classify time zone names into three historic eras. In the oldest era,
you have zone names like EST5EDT which are composed of three pieces.
The first piece, EST, is the zone's name when the clock is "normal" (not
daylight saving or summer time). The second piece, 5, is the number
of hours behind GMT the clock is (normally). The third piece, EDT, is
the zone's name when daylight saving time is in effect.
In the second era, zone names look like "US/Eastern". The piece on the
right hand side is a component of the piece on the left. I'm uncertain
whether the pieces on the left are always country codes, or if there's
some other arrangement.
In the modern era, zone names look like "America/Chicago". The piece on
the left is a continent (or other large geographic region, e.g. "Pacific"),
and the piece on the right is a major city, preferably *the* major city,
which exemplifies the specific time zone in question.
For you and me, the current era time zone name is "America/New_York".
This is how the Debian installer sets the localtime symlink, and is
what we should be using if we have to set it ourselves.
I personally find "US/Eastern" the easiest to grasp, and I'm sad that
this pattern fell out of fashion, for whatever reason. Whenever I tell
people on the Internet (who may not be Linux users) what time zone I'm
in, I always go with "US/Eastern". It's just so *clear*.
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2023-12-04 22:50 +0100 |
| Message-ID | <HHoZb-bbjg-1@gated-at.bofh.it> |
| In reply to | #264248 |
On Mon 04 Dec 2023 at 15:36:32 (-0500), Greg Wooledge wrote: > I classify time zone names into three historic eras. In the oldest era, > you have zone names like EST5EDT which are composed of three pieces. > The first piece, EST, is the zone's name when the clock is "normal" (not > daylight saving or summer time). The second piece, 5, is the number > of hours behind GMT the clock is (normally). The third piece, EDT, is > the zone's name when daylight saving time is in effect. > > In the second era, zone names look like "US/Eastern". The piece on the > right hand side is a component of the piece on the left. I'm uncertain > whether the pieces on the left are always country codes, or if there's > some other arrangement. > > In the modern era, zone names look like "America/Chicago". The piece on > the left is a continent (or other large geographic region, e.g. "Pacific"), > and the piece on the right is a major city, preferably *the* major city, > which exemplifies the specific time zone in question. > > For you and me, the current era time zone name is "America/New_York". > This is how the Debian installer sets the localtime symlink, and is > what we should be using if we have to set it ourselves. > > I personally find "US/Eastern" the easiest to grasp, and I'm sad that > this pattern fell out of fashion, for whatever reason. Whenever I tell > people on the Internet (who may not be Linux users) what time zone I'm > in, I always go with "US/Eastern". It's just so *clear*. Because they don't work historically; for example, say you live in Wayne Co, KY: /usr/share/zoneinfo$ for j in America/Kentucky/*; do TZ="$j" date -d '@907654321'; done Tue Oct 6 02:12:01 EDT 1998 Tue Oct 6 01:12:01 CDT 1998 /usr/share/zoneinfo$ for j in America/Kentucky/*; do TZ="$j" date -d '@987654321'; done Thu Apr 19 00:25:21 EDT 2001 Thu Apr 19 00:25:21 EDT 2001 /usr/share/zoneinfo$ Cheers, David.
[toc] | [prev] | [next] | [standalone]
| From | jeremy ardley <jeremy.ardley@gmail.com> |
|---|---|
| Date | 2023-12-05 00:50 +0100 |
| Message-ID | <HHqRj-bcLK-5@gated-at.bofh.it> |
| In reply to | #264248 |
On 5/12/23 04:52, Darac Marjal wrote: > > Most people know what timezone they're currently in, but the more > likely know what their nearest city is. Cities rarely change, but > timezones do. Take the example of Triana in Paul Eggert's original > email. The city never moved, but the timezone it was it changed dozens > of times. Its a lot easier for someone to configure Europe/Tirana than > to have to keep changing timezones. The problem with that approach is when reviewing historical events there is no easy way to know what the local time was at any specific date This is precisely the same problem as daylight saving which afflicts a large number of cities, though easier to pin the time down. In my country we have different names for daylight saving time and normal time. e.g. Sydney Australia is AEDT at the moment while a few months ago it was AEST If I referred to timezone Australia/Sydney I'd have to go and look up the daylight saving dates. In my hometown of Perth we had daylight saving for a bit but gave up on it. So Australia/Perth timezone is fixed at AWST but at dates I don't precisely recall could have been AWDT
[toc] | [prev] | [next] | [standalone]
| From | gene heskett <gheskett@shentel.net> |
|---|---|
| Date | 2023-12-04 21:30 +0100 |
| Message-ID | <HHnJL-bajD-11@gated-at.bofh.it> |
| In reply to | #264209 |
On 12/4/23 07:17, Greg Wooledge wrote: >> ls -hal /etc/localtime >> lrwxrwxrwx 1 root root 27 Nov 1 18:21 /etc/localtime -> >> /usr/share/zoneinfo/EST5EDT And using mc to edit that link fixed it, I am now getting the correct time from date, thank you a lot. But maybe a bug against tzselect s/b filed, IMNSHO it should have fixed that. It did not. Cheers, Gene Heskett. -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis
[toc] | [prev] | [next] | [standalone]
| From | Pocket <pocket@columbus.rr.com> |
|---|---|
| Date | 2023-12-04 23:20 +0100 |
| Message-ID | <HHpsd-bbNf-1@gated-at.bofh.it> |
| In reply to | #264247 |
On 12/4/23 15:28, gene heskett wrote: > On 12/4/23 07:17, Greg Wooledge wrote: > >>> ls -hal /etc/localtime >>> lrwxrwxrwx 1 root root 27 Nov 1 18:21 /etc/localtime -> >>> /usr/share/zoneinfo/EST5EDT > > And using mc to edit that link fixed it, I am now getting the correct > time from date, thank you a lot. > > But maybe a bug against tzselect s/b filed, IMNSHO it should have > fixed that. It did not. > > Cheers, Gene Heskett. For gene.................................................................. #!/usr/bin/dash #----------------------------------------------------------------------------- # Title: timezone.sh # Date: 2023-12-04 # Version: 1.0 # Author: pocket@columbus.rr.com #----------------------------------------------------------------------------- set -o errexit # exit if error...insurance ;) set -o nounset # exit if variable not initialized #----------------------------------------------------------------------------- zone=EST5EDT zoneinfo=/usr/share/zoneinfo localtime=/etc/localtime timezone=/etc/timezone profile=/etc/profile.d if [ -e "$zoneinfo"/"$zone" ];then ln -sf "$zoneinfo"/"$zone" "$localtime" else printf "%s\n" "Invalid zone: $zoneinfo/$zone" exit 1 fi printf "%s\n" "$zone" > "$timezone" printf "%s\n" "TZ=$zone;export TZ" > "$profile"/timezone.sh chmod +x "$profile"/timezone.sh #----------------------------------------------------------------------------- chmod +x timezone.sh sudo ./timezone.sh -- It's not easy to be me
[toc] | [prev] | [next] | [standalone]
| From | Max Nikulin <manikulin@gmail.com> |
|---|---|
| Date | 2023-12-05 17:40 +0100 |
| Message-ID | <HHGCK-brjs-3@gated-at.bofh.it> |
| In reply to | #264256 |
On 05/12/2023 05:14, Pocket wrote:
> For gene..................................................................
[...]
> zone=EST5EDT
> zoneinfo=/usr/share/zoneinfo
> localtime=/etc/localtime
> timezone=/etc/timezone
> profile=/etc/profile.d
> if [ -e "$zoneinfo"/"$zone" ];then
> ln -sf "$zoneinfo"/"$zone" "$localtime"
> else
> printf "%s\n" "Invalid zone: $zoneinfo/$zone"
> exit 1
> fi
> printf "%s\n" "$zone" > "$timezone"
> printf "%s\n" "TZ=$zone;export TZ" > "$profile"/timezone.sh
To set /etc/localtime and /etc/timezone I would recommend the command
that has been repeated several times in this thread:
dpkg-reconfigure tzdata
And I would recommend against setting the TZ environment variable unless
it is really necessary. If somebody needs it then it is better to do it
in /etc/environment.d as well. KDE has its own GUI to set user-specific
timezone, but I am unsure if selected value will be applied in the case
of console or ssh login.
I am surprised that POSIX EST5EDT timezone has irregularities at least
as it is implemented in GNU libc. I believed that it specifies just
standard and summer time.
LANG=C.UTF-8 TZ=EST5EDT date -d 'TZ="Z" 1940-01-01 00:00'
Sun Dec 31 19:00:00 EST 1939
LANG=C.UTF-8 TZ=EST5EDT date -d 'TZ="Z" 1943-01-01 00:00'
Thu Dec 31 20:00:00 EWT 1942
However since these rules are specific to US, I would prefer IANA
identifiers like America/New_York.
https://naggum.no/lugm-time.html
Erik Naggum. A Long, Painful History of Time. 1999
> 8.2 Timezone Representation
>
> David Olsen of Digital Equipment Corporation has laid down a tremendous
> amount of work in collecting the timezones of the world and their
> daylight saving time boundaries. Contrary to the Unix System V approach
> from New Jersey (insert appropriate booing for best effect), which
> codifies a daylight saving time regime only for the current year, and
> apply it to all years, David Olsen's approach is to maintain tables of
> all the timezone changes.
[toc] | [prev] | [next] | [standalone]
| From | Pocket <pocket@columbus.rr.com> |
|---|---|
| Date | 2023-12-05 18:10 +0100 |
| Message-ID | <HHH5L-brNo-13@gated-at.bofh.it> |
| In reply to | #264297 |
On 12/5/23 11:37, Max Nikulin wrote: > > On 05/12/2023 05:14, Pocket wrote: >> For >> gene.................................................................. > [...] >> zone=EST5EDT >> zoneinfo=/usr/share/zoneinfo >> localtime=/etc/localtime >> timezone=/etc/timezone >> profile=/etc/profile.d >> if [ -e "$zoneinfo"/"$zone" ];then >> ln -sf "$zoneinfo"/"$zone" "$localtime" >> else >> printf "%s\n" "Invalid zone: $zoneinfo/$zone" >> exit 1 >> fi >> printf "%s\n" "$zone" > "$timezone" >> printf "%s\n" "TZ=$zone;export TZ" > "$profile"/timezone.sh > > To set /etc/localtime and /etc/timezone I would recommend the command > that has been repeated several times in this thread: > > dpkg-reconfigure tzdata That does not work. Cannot set EST5EDT. you have to do that manually. You also can not select any of the POSIX time zones which indecently EST5EDT is one of those > And I would recommend against setting the TZ environment variable > unless it is really necessary. If somebody needs it then it is better > to do it in /etc/environment.d as well. KDE has its own GUI to set > user-specific timezone, but I am unsure if selected value will be > applied in the case of console or ssh login. I don't use KDE, I am using LXDE and systems without desktops. Comment that part out of the shell script. I script all my setups, so I can apply them to all the systems I have. For example: openssh-server.sh bind.sh nginx.sh nfs-client.sh nfs-server.sh The scripts install the debian packages required and then setup the configuration. > > I am surprised that POSIX EST5EDT timezone has irregularities at least > as it is implemented in GNU libc. I believed that it specifies just > standard and summer time. > > LANG=C.UTF-8 TZ=EST5EDT date -d 'TZ="Z" 1940-01-01 00:00' > Sun Dec 31 19:00:00 EST 1939 > > LANG=C.UTF-8 TZ=EST5EDT date -d 'TZ="Z" 1943-01-01 00:00' > Thu Dec 31 20:00:00 EWT 1942 > > However since these rules are specific to US, I would prefer IANA > identifiers like America/New_York. Which is why I use it. /usr/share/zoneinfo/posix/EST5EDT is a symlilnk to /usr/share/zoneinfo/EST5EDT > > https://naggum.no/lugm-time.html > Erik Naggum. A Long, Painful History of Time. 1999 >> 8.2 Timezone Representation >> >> David Olsen of Digital Equipment Corporation has laid down a tremendous >> amount of work in collecting the timezones of the world and their >> daylight saving time boundaries. Contrary to the Unix System V approach >> from New Jersey (insert appropriate booing for best effect), which >> codifies a daylight saving time regime only for the current year, and >> apply it to all years, David Olsen's approach is to maintain tables of >> all the timezone changes. > > > -- It's not easy to be me
[toc] | [prev] | [next] | [standalone]
| From | Max Nikulin <manikulin@gmail.com> |
|---|---|
| Date | 2023-12-06 13:30 +0100 |
| Message-ID | <HHZcl-bGOX-5@gated-at.bofh.it> |
| In reply to | #264298 |
On 06/12/2023 00:03, Pocket wrote: > On 12/5/23 11:37, Max Nikulin wrote: >> On 05/12/2023 05:14, Pocket wrote: >>> For gene........................................................ [...] >> >> dpkg-reconfigure tzdata > > That does not work. Cannot set EST5EDT. you have to do that manually. Do you have reasons to prefer EST5EDT to IANA identifiers like America/Detroit, America/New_York, etc. (that have some differences from EST5EDT)? Location-based time zones should be more precise for most of users. I find it reasonable that "dpkg-reconfigure tzdata" forces users to set a timezone that should provide more accurate results for them. I have seen America/New_York in a couple of Gene's messages including https://lists.debian.org/msgid-search/7ba9b8bc-2929-4a3d-8007-a1b5c7f6fc16@shentel.net so I assume it is one that he should use. My impression is that EST5EDT appeared unintentionally. > I don't use KDE, I am using LXDE and systems without desktops. > > Comment that part out of the shell script. Do you really need TZ environment variable especially set to the value in system-wide configuration? In the Gene's case I mentioned it for the case that some piece of software decided to set it, but I have not recommended to set it. It is a way to make debugging of a next issue harder. Sorry, I do not have a VM with LXDE to check if TZ is actually set for applications. It may depend on display manager configuration and on the approach to launch applications: window manager children or systemd session. Anyway I noticed "For gene" and I remember that he uses KDE that has a GUI for it. However I am unsure if KDE is installed to this 3d printer controller. > Which is why I use it. > > /usr/share/zoneinfo/posix/EST5EDT is a symlilnk to > /usr/share/zoneinfo/EST5EDT And it is rather confusing since arbitrary abbreviations may be used to specify POSIX time zones, e.g. ABC5DEF. From my point of view, it is just legacy since the time zone database is available. It was painful when JavaScript (ECMAScript 5) had fixed DST rules based on current regulations. Chrome followed the standard, Firefox used accurate history of time transitions. I have not checked POSIX, but I see that GNU libc approach is something third in between. Let's use time zones that allows to get accurate local time.
[toc] | [prev] | [next] | [standalone]
| From | Pocket <pocket@columbus.rr.com> |
|---|---|
| Date | 2023-12-06 14:10 +0100 |
| Message-ID | <HHZP3-bHjc-5@gated-at.bofh.it> |
| In reply to | #264322 |
On 12/6/23 07:22, Max Nikulin wrote: > On 06/12/2023 00:03, Pocket wrote: >> On 12/5/23 11:37, Max Nikulin wrote: >>> On 05/12/2023 05:14, Pocket wrote: > >>>> For gene........................................................ > [...] >>> >>> dpkg-reconfigure tzdata >> >> That does not work. Cannot set EST5EDT. you have to do that manually. > > Do you have reasons to prefer EST5EDT to IANA identifiers like > America/Detroit, America/New_York, etc. (that have some differences > from EST5EDT)? Location-based time zones should be more precise for > most of users. > > I find it reasonable that "dpkg-reconfigure tzdata" forces users to > set a timezone that should provide more accurate results for them. I follow POSIX > > I have seen America/New_York in a couple of Gene's messages including > https://lists.debian.org/msgid-search/7ba9b8bc-2929-4a3d-8007-a1b5c7f6fc16@shentel.net > > so I assume it is one that he should use. My impression is that > EST5EDT appeared unintentionally. > I introduced EST5DST to this by simply posted my configuration. >> I don't use KDE, I am using LXDE and systems without desktops. >> >> Comment that part out of the shell script. > > Do you really need TZ environment variable especially set to the value > in system-wide configuration? In the Gene's case I mentioned it for > the case that some piece of software decided to set it, but I have not > recommended to set it. It is a way to make debugging of a next issue > harder. > I doesn't hurt anything, What if I install some application that uses it and it is not set? > Sorry, I do not have a VM with LXDE to check if TZ is actually set for > applications. It may depend on display manager configuration and on > the approach to launch applications: window manager children or > systemd session. > > Anyway I noticed "For gene" and I remember that he uses KDE that has a > GUI for it. However I am unsure if KDE is installed to this 3d printer > controller. > >> Which is why I use it. >> >> /usr/share/zoneinfo/posix/EST5EDT is a symlilnk to >> /usr/share/zoneinfo/EST5EDT > > And it is rather confusing since arbitrary abbreviations may be used > to specify POSIX time zones, e.g. ABC5DEF. From my point of view, it > is just legacy since the time zone database is available. > > It was painful when JavaScript (ECMAScript 5) had fixed DST rules > based on current regulations. Chrome followed the standard, Firefox > used accurate history of time transitions. I have not checked POSIX, > but I see that GNU libc approach is something third in between. > > Let's use time zones that allows to get accurate local time. You use want works for you I will use what works for me. Anyway I will use the timezone that I wish to use and that is EST5EDT. All my systems are set to POSIX standards. cat /etc/default/locale LANG=POSIX
[toc] | [prev] | [next] | [standalone]
| From | Max Nikulin <manikulin@gmail.com> |
|---|---|
| Date | 2023-12-06 16:10 +0100 |
| Message-ID | <HI1Hb-bIYg-3@gated-at.bofh.it> |
| In reply to | #264325 |
On 06/12/2023 20:08, Pocket wrote: > On 12/6/23 07:22, Max Nikulin wrote: >> On 06/12/2023 00:03, Pocket wrote: >>> On 12/5/23 11:37, Max Nikulin wrote: >>>> dpkg-reconfigure tzdata >>> >>> That does not work. Cannot set EST5EDT. you have to do that manually. >> >> Do you have reasons to prefer EST5EDT to IANA identifiers like >> America/Detroit, America/New_York, etc. (that have some differences >> from EST5EDT)? Location-based time zones should be more precise for >> most of users. [...] > I follow POSIX There are enough oversights in various standards. When accurate time zone DB is unavailable, POSIX ones might be used (if risk to get wrong results is accepted). Otherwise, from my of view, it is a legacy to keep aside and a kind of cargo cult. That is why I asked concerning your reasons. > I introduced EST5DST to this by simply posted my configuration. Maybe due to language barrier I perceived it as a recommendation for Gene. The same time zone appeared earlier in a Gene's message. Perhaps he still has it as the /etc/localtime link target. Of course, you are free to have whatever you want in your configuration. Please, be responsible suggesting anything to others. >> Do you really need TZ environment variable especially set to the value >> in system-wide configuration? [...] > I doesn't hurt anything, What if I install some application that uses it > and it is not set? It may cause waste of time when you will need to change time zone. If not all occurrences are updated you may see wrong time. For me it is a reason to avoid unnecessary settings. > cat /etc/default/locale > LANG=POSIX Does it set UTF-8 encoding? Sometimes I use C.UTF-8. However there are enough subtle differences (sorting, etc.) from any en_* locale.
[toc] | [prev] | [next] | [standalone]
| From | Pocket <pocket@columbus.rr.com> |
|---|---|
| Date | 2023-12-06 16:50 +0100 |
| Message-ID | <HI2jT-bJnm-5@gated-at.bofh.it> |
| In reply to | #264332 |
On 12/6/23 10:07, Max Nikulin wrote: > On 06/12/2023 20:08, Pocket wrote: >> On 12/6/23 07:22, Max Nikulin wrote: >>> On 06/12/2023 00:03, Pocket wrote: >>>> On 12/5/23 11:37, Max Nikulin wrote: >>>>> dpkg-reconfigure tzdata >>>> >>>> That does not work. Cannot set EST5EDT. you have to do that manually. >>> >>> Do you have reasons to prefer EST5EDT to IANA identifiers like >>> America/Detroit, America/New_York, etc. (that have some differences >>> from EST5EDT)? Location-based time zones should be more precise for >>> most of users. > [...] >> I follow POSIX > > There are enough oversights in various standards. When accurate time > zone DB is unavailable, POSIX ones might be used (if risk to get wrong > results is accepted). Otherwise, from my of view, it is a legacy to > keep aside and a kind of cargo cult. That is why I asked concerning > your reasons. Well POSIX has worked for me since the days of Xenix and System V. > >> I introduced EST5DST to this by simply posted my configuration. > > Maybe due to language barrier I perceived it as a recommendation for > Gene. The same time zone appeared earlier in a Gene's message. Perhaps > he still has it as the /etc/localtime link target. Of course, you are > free to have whatever you want in your configuration. Please, be > responsible suggesting anything to others. I post what works for and the information I have found due to my research. It doesn't mean what I use will work or solve others issues. If it offends you then so be it. Many times I will research an issue and NOT use what others posted as it doesn't work for me. I may end up finding my own solution. > >>> Do you really need TZ environment variable especially set to the >>> value in system-wide configuration? > [...] >> I doesn't hurt anything, What if I install some application that uses >> it and it is not set? > > It may cause waste of time when you will need to change time zone. If > not all occurrences are updated you may see wrong time. For me it is a > reason to avoid unnecessary settings. Which is why I use a script to change it > >> cat /etc/default/locale >> LANG=POSIX > > Does it set UTF-8 encoding? Sometimes I use C.UTF-8. However there are > enough subtle differences (sorting, etc.) from any en_* locale. > > locale charmap ANSI_X3.4-1968 -- It's not easy to be me
[toc] | [prev] | [next] | [standalone]
| From | Greg Wooledge <greg@wooledge.org> |
|---|---|
| Date | 2023-12-06 17:20 +0100 |
| Message-ID | <HI2MV-bJUe-1@gated-at.bofh.it> |
| In reply to | #264333 |
On Wed, Dec 06, 2023 at 10:44:42AM -0500, Pocket wrote: > Well POSIX has worked for me since the days of Xenix and System V. Well, most of the goofy time zone changes were all *before* that. But there's at least one that happened more recently.... unicorn:~$ TZ=EST5EDT date -d '2006-03-12 +4 hours' Sun Mar 12 04:00:00 EST 2006 unicorn:~$ TZ=EST5EDT date -d '2007-03-11 +4 hours' Sun Mar 11 05:00:00 EDT 2007 So, OK, I guess the EST5EDT time zone in Debian 12 properly handles the change to start of DST in the US in 2007 (and more specifically, handles dates *older* than that using the historic rules instead of the current rules). Looking at other periods of interest from Wikipedia: unicorn:~$ TZ=EST5EDT date -d '1987-04-05 +4 hours' Sun Apr 5 05:00:00 EDT 1987 unicorn:~$ TZ=EST5EDT date -d '1974-01-06 +4 hours' Sun Jan 6 05:00:00 EDT 1974 unicorn:~$ TZ=EST5EDT date -d '1967-04-30 +4 hours' Sun Apr 30 05:00:00 EDT 1967 I guess EST5EDT in Debian 12 is more like a synonym for America/New_York than a real historical EST5EDT as described by Erik Naggum <https://naggum.no/lugm-time.html>. If this is satisfactory, then you can continue using the legacy time zone without running into problems. At least on current Debian systems. I wouldn't know how well-behaved that time zone is on other systems. Honestly, I don't see the appeal of using legacy time zone names. Is it just for the sake of contrariness?
[toc] | [prev] | [next] | [standalone]
| From | Pocket <pocket@columbus.rr.com> |
|---|---|
| Date | 2023-12-06 17:30 +0100 |
| Message-ID | <HI2WB-bK0N-9@gated-at.bofh.it> |
| In reply to | #264337 |
On 12/6/23 11:18, Greg Wooledge wrote: > On Wed, Dec 06, 2023 at 10:44:42AM -0500, Pocket wrote: >> Well POSIX has worked for me since the days of Xenix and System V. > Well, most of the goofy time zone changes were all *before* that. But > there's at least one that happened more recently.... > > unicorn:~$ TZ=EST5EDT date -d '2006-03-12 +4 hours' > Sun Mar 12 04:00:00 EST 2006 > > unicorn:~$ TZ=EST5EDT date -d '2007-03-11 +4 hours' > Sun Mar 11 05:00:00 EDT 2007 > > So, OK, I guess the EST5EDT time zone in Debian 12 properly handles > the change to start of DST in the US in 2007 (and more specifically, > handles dates *older* than that using the historic rules instead of > the current rules). > > Looking at other periods of interest from Wikipedia: > > unicorn:~$ TZ=EST5EDT date -d '1987-04-05 +4 hours' > Sun Apr 5 05:00:00 EDT 1987 > > unicorn:~$ TZ=EST5EDT date -d '1974-01-06 +4 hours' > Sun Jan 6 05:00:00 EDT 1974 > > unicorn:~$ TZ=EST5EDT date -d '1967-04-30 +4 hours' > Sun Apr 30 05:00:00 EDT 1967 > > I guess EST5EDT in Debian 12 is more like a synonym for America/New_York > than a real historical EST5EDT as described by Erik Naggum > <https://naggum.no/lugm-time.html>. > > If this is satisfactory, then you can continue using the legacy time > zone without running into problems. At least on current Debian systems. > I wouldn't know how well-behaved that time zone is on other systems. I used POSIX time zones on other systems including my custom scratch built ones. The custom built systems was built using a cross compiler for the AMD64, aarch64 and armv7a platforms. Never had an issue. Don't see what the issue is here? > > Honestly, I don't see the appeal of using legacy time zone names. Is > it just for the sake of contrariness? > diff /usr/share/zoneinfo/EST5EDT /usr/share/zoneinfo/America/New_York Binary files /usr/share/zoneinfo/EST5EDT and /usr/share/zoneinfo/America/New_York differ Because I can ;} -- It's not easy to be me
[toc] | [prev] | [next] | [standalone]
| From | Greg Wooledge <greg@wooledge.org> |
|---|---|
| Date | 2023-12-06 17:50 +0100 |
| Message-ID | <HI3fX-bKeG-9@gated-at.bofh.it> |
| In reply to | #264339 |
On Wed, Dec 06, 2023 at 11:28:40AM -0500, Pocket wrote: > diff /usr/share/zoneinfo/EST5EDT /usr/share/zoneinfo/America/New_York > Binary files /usr/share/zoneinfo/EST5EDT and > /usr/share/zoneinfo/America/New_York differ unicorn:/usr/share/zoneinfo$ ls -l EST5EDT -rw-r--r-- 1 root root 2310 May 28 2023 EST5EDT unicorn:/usr/share/zoneinfo$ ls -l America/New_York -rw-r--r-- 1 root root 3552 May 28 2023 America/New_York unicorn:/usr/share/zoneinfo$ file EST5EDT EST5EDT: timezone data (fat), version 2, 5 gmt time flags, 5 std time flags, no leap seconds, 149 transition times, 5 local time types, 16 abbreviation chars unicorn:/usr/share/zoneinfo$ file America/New_York America/New_York: timezone data (fat), version 2, 6 gmt time flags, 6 std time flags, no leap seconds, 236 transition times, 6 local time types, 20 abbreviation chars OK, they are definitely not the same. I don't feel like digging through them to try to figure out *what* the differences are, but clearly there must be *some* point(s) in time where they give different results. If you wish to continue using the legacy time zone, knowing that it's different from the proper one (but not precisely in what way), then on your own head be it. For comparison, this one is cleary safe to use: unicorn:/usr/share/zoneinfo$ ls -l US/Eastern lrwxrwxrwx 1 root root 19 May 28 2023 US/Eastern -> ../America/New_York
[toc] | [prev] | [next] | [standalone]
| From | Curt <curty@free.fr> |
|---|---|
| Date | 2023-12-06 17:50 +0100 |
| Message-ID | <HI3fX-bKeG-7@gated-at.bofh.it> |
| In reply to | #264337 |
On 2023-12-06, Greg Wooledge <greg@wooledge.org> wrote: > > Honestly, I don't see the appeal of using legacy time zone names. Is > it just for the sake of contrariness? > No lack of contrariness around here. There exists such a thing as putting too fine a point on a thing, a notion which appears to escape some technical mentalities. In defence of time zones (they don't really need it, I guess): Why are the clocks in Urumqi, China, so far out of kilter with the cycles of the sun? Because of a legacy of Mao Zedong and the Communist Party’s desire for unified control. Though China is almost as wide as the continental United States, the whole country is officially in just one time zone — Beijing time. So when it’s 7 a.m. in the Forbidden City, it’s also officially 7 a.m. 2,000 miles to the west in Urumqi, the capital of the Xinjiang region — even if the stars are still out there. That can lead to headaches — and lost sleep. “It’s hard to adjust,” says Gao Li, a sanitation worker in Urumqi. “I often think we must be the only people who eat dinner at midnight.” So schools, airports and train stations operate at odd hours; national exams are sometimes given in the dead of night; and restaurants stay open for dinner into the wee hours. The eccentricities of the clock also tend to divide people in Xinjiang by ethnicity. The Uighurs, Turkic-speaking Muslims who consider the region their homeland, tend to set their clocks two hours earlier, to more closely match the local day. But the Han Chinese who live there, members of China’s predominant ethnic group, generally follow Beijing time. The discrepancies can be a source of confusion and frustration, especially for younger people who frequently socialize across ethnic lines. https://www.nytimes.com/2016/06/17/world/asia/china-single-time-zone.html
[toc] | [prev] | [next] | [standalone]
Page 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
Back to top | Article view | linux.debian.user
csiph-web