During the installation i couldn’t see any way to select a non-geographic TimeZone. Is there some reason for this please?
Reason:
I’m old enough to remember the “experiment” the UK had when it didn’t play about with the clocks twice a year and it was glorious - if only so people could not say they over-slept because "they forgot to put their clocks forward/backwards/upside down/whatever.
p.s.
Yes, thanks i do know how to change it after the install but not before i have messed up log files.
Can you explain what you mean by this, as I struggle to get it? (maybe because I’m not a native English speaker?..)
Maybe you want to set only hours difference to Universal, instead of selecting a country?
In a terminal, going to:
/usr/share/zoneinfo/
shows several entries that could solve your problem.
There is “Universal” “UCT” “UTC” four “GMT’” zones.
One would have to play around to see which might work.
Pudge
@petsam
non-geographic, as in not related yo, and changing with, a geographic location,
e.g.
GMT - the “original” TZ
Thanks @Pudge
Yes, but that’s now, i.e. after the install.
What i wanted, would like, wanted to know why not when some/many other distro’s do, was being able to set on of those ETC group TZ’s during the install process - instead of setting, in my case, Europe/London.
Why are all of those TZ’s shown in zoneinfo not available during an install?
It looks as if someone has specifically decided to offer only a geographic subset of that zoneinfo file, instead of the entire file, during an install, why?
Is there a reason?
I’m not sure there’s a valid reason to keep on asking this question. If you feel there’s a feature missing from Calamares then open a feature request.
Sorry @jonathon but since other distro’s (most, even all i can remember) offer the entire set of TZ’s, this would seem to be more of a specific exclusion to me. Let’s face it, the “ETC” subset didn’t jump out on its own! If that is the case, then i would have thought that someone had done it for a reason.
I was just asking…
As requested by @jonathon i have created a post requesting this feature.
General System:
Installation:
Feature request: Make all TZ’s available during install
Sorry. I think there may have been some confusion. You don’t request a feature to Calamares(the installer we use) by opening another topic on the Forum.
To request a feature to be added to Calamares, you can do so here:
You beat me by a minute 
Sorry @dalto buy is it really calamares that doesn’t allow an ETC setting? I assumed that it was the choice of list that the EOS developers were passing to calamares as i’ve used other distro’s which use calamares (a while ago) and i’m pretty sure that they included the ETC group.
The default config with descriptions for that module is here:
I don’t see any options like that.
Thanks for that, now i see what’s been confusing me, viz:
it’s because of the “pin-on-the-map” and that then tying the TZ only to locations.
Although it would seem that i should have been able to do as i wanted with the “useSystemTimezone” option (see below).
Do you know how that set? And is it possible for a user to set it before any files are written during the install please?
Prior to running the installer, edit /etc/calamares/modules/locale.conf and add useSystemTimezone: true. The file is indentation-specific so ensure there are no spaces or other whitespace in front of it.
Although, wouldn’t it be easier to change the timezone after you first boot into the installation?
Hi @dalto.
First of, i’m already up and running and too busy having fun re-writing my scripts (although that’s difficult as i have a house full atm).
Also i had issues during the installation, i even saved some files, but i got past them and all is now fine.
Yeah, you’re probably right, although i do hate file timestamps not matching, plus i’m not sure i’d be happy even trying to modify a live installation.
I guess if i ever need to re-install … however, by then i’m betting i won’t be able to find your solution “;)”
Thanks again.
Thanks to all, it’s a lovely distro.
Timezones shouldn’t have any impact on file timestamps. The timezone is an offset. You can change your timezone whenever you want. Some people who travel change their timezone as they are travelling.
It seems like an xyproblem.info case, to me…
If file timestamps is the real issue, as @dalto said, use GMT. TimeZone setting is used only for output, like File Managers, command listing (ls -l) and such.
post 4
Yes, that’s exactly what i use, well, a GMT equivalent.
When a file says it was created/updated/accessed at a certain time and i am comparing that with other files which show a different time then i would really like to know that those times are based on the same “offset” (as you quite rightly point out). Maybe I am just being pedantic, after all, as you rightly say, i’m sure there are lots of people who will happily change their TZ’s as they travel around the globe … sorry but that wouldn’t do for me. Although, TBH, i can’t see how that would work with any backup programmes i’ve looked at or even the cp/rsync commands - I only use those two commands so maybe there are other Linux CLI commands that can handle timezones that periodically change. Plus i know for a fact that the British military use only one timezone, “Zulu”, regardless of where they might be located. And for good reason too as there are certainly historic examples of military campigns going badly wrong because everyone wasn’t using the same TZ. I would have thought that knowing everyone was using the same TZ might also be important in some other fields too, such as international banking. Furthermore, i know that one of the Universal (static) TZ’s is definitely used for atomic clocks (UTC), air traffic control (UTC), aviation (UTC), weather forecasting (UTC), mapping (probably UTC), GPS (UTC), on spacecraft (UTC), observations in space (UTC), NASA (UTC). JPL (UTC), the entire worlds scientific community (GMT/UTC), the Deep Space Atomic Clock (UTC I think) and at the International Space Station (Zulu/GMT) too. Plus I would be very surprised if there were any satelites that used anything but one of the “Universal” timezones, i.e. not use a TZ tied to a geographic location.
That isn’t how timestamps work. Timestamps are not stored in your timezone. They are stored in a timezone neutral way. The timezone only impacts how you see the files.
As an example, lets say your timezone is set to GMT. You create a file at 9AM. The timestamp shows 9:00 when you look at in your file manager(or using any other program).
Now you change your time zone to be GMT+2. If you look at that same file the timestamp will now show 11:00. The timestamp on the file hasn’t changed, you are just seeing it differently.
In other words, a time zone change isn’t like if you actually changed the system clock.
Those programs won’t be impacted by a time zone change for the reasons above. The timestamp isn’t actually changing in the underlying storage.
In short, a long time ago mariners realised how important it was to have accurate time. Then the English railways realised how important it was to have the same time for all, well, “all” in their coverage area.
Then along came politicians and they kowtowed to the big land owners by agreeing to mess with those great steps forward and they changed the clocks twice a year so that workers could work longer hours in the evenings because no-one had decent lighting in those days.
Now we have great lighting, there’s no excuse, so why on earth are we still kowtowing to the land owners by changing our clocks twice a year? After the three year “experiment” started in 1968 by a UK Labour Government, most people did not want to revert to “the old system”. Except those same landowners. RoSPA want the UK to stay on BST to save lives. Most experts agree that circadian misalignment can carry higher risks of some serious health conditions, including obesity, metabolic disorders, cardiovascular issues, depression and even cancer.
I’m doing my bit now.
p.s.
It did start off “short”.