some Pacific time zones and offsets as of 2026-08-19; observations on Linux, Unix, MacOS, iOS timezone handling

Crossing the Pacific westwards, the ship's time gets set back one hour at a time.  The ship's management arranges it so that at land stops, it is synchronised with the location.  Changes between one stop and the next are somewhat arbitrary, but the idea should be to keep changes smooth and have dawn and dusk at sensible wall times.

I set around 5 clocks at each change.

The Casio F-91W is the easiest.  I set the hour back using the three buttons on the watch.  The only annoyance is that I have to cycle +23 hours, as one can not decrement the hour directly.  It's not that annoying, and one knows it's going to work.

For the Debian (Linux) laptop, I change the /etc/localtime symlink to point to location in /usr/share/zoneinfo/*/*, such as /usr/share/zoneinfo/America/Vancouver.  This is fine when there is a well-known city to select.  It sometimes involves research and experimentation to choose one with the correct (current) offset.  Once the symlink changes, the time displayed by the GNOME clock in the desktop's top bar changes instantly.

On MacOS, I search in settings for "zone", and go into the time config.  It doesn't have all the same locations as Linux.  Searching for a string can crash the Settings application.  As a fallback, one can set both zone and time to manual, leave it on the wrong zone, and set the time.  But this is Pyrrhic.  The displayed wall time might be right, but timestamps and displayed times in calendars and other applications will be wrong.  A ship appointment, say 15:00 Tea, will show simply as 14:00 Tea (or whatever) on calendar viewed with wrong time config.  I can't seem to get calendars to display an explicit time offset or zone next to every displayed time, which would be the config making sense for many travellers.

On the iPhone, searching settings for "zone" can easily lead one to a different setting that doesn't change the timezone.  Having navigated that pitfall, the locations are not the same set of locations as in MacOS.  A similar fallback is possible if one can't find a matching location, with the same drawback as for MacOS.

If someone has an Apple Watch, but the iPhone that controls it isn't working, then there is no way to change the time on the Apple Watch back in increments of one hour.  One low-tech workaround is to put a sticker on the watch's face with the adjustment to make from the time the watch displays, such as "-4".

The ship displays the time on LCDs on the wired phones in the rooms, on the app, on big screens, on analogue clock faces.  There is supposed to be a talking clock from the room phone, but I didn't get it to work.  The Bridge makes an announcement at 12 noon ship-time every day.  The screen on the wired phones seems to be reliable.  The time shown on the app is sometimes an hour out, the day after a change.

There should be a set of abstract timezones, defined with constant offsets relative to UTC.  These could be called "Plus1", "Plus2", "Plus3", "Plus4" .. "Plus20", "Plus21", "Plus22", "Plus23" and "Minus1" .. "Minus23", as well as something like "ZeroUTC".  This would allow people in oceans or obscure locations to easily select a timezone that works correctly for them.

In timezone-selection interfaces, it should be possible to search for a zone by its current offset.  So searching today for +1 would bring up Europe/London and a bunch of other locations.

In Linux, there is the advantage of being to look in /usr/share/zoneinfo/*.

For me on Debian 13, there are 41 entries under /usr/share/zoneinfo/Pacific.  These are as follows, with current offsets given as of today 2026-08-19:

• Pacific/Midway: -11
• Pacific/Niue: -11
• Pacific/Pago_Pago: -11
• Pacific/Samoa: -11
• Pacific/Honolulu: -10
• Pacific/Johnston: -10
• Pacific/Rarotonga: -10
• Pacific/Tahiti: -10
• Pacific/Marquesas: -9:30
• Pacific/Gambier: -9
• Pacific/Pitcairn: -8
• Pacific/Easter: -6
• Pacific/Galapagos: -6
• Pacific/Palau: +9
• Pacific/Chuuk: +10
• Pacific/Guam: +10
• Pacific/Port_Moresby: +10
• Pacific/Saipan: +10
• Pacific/Yap: +10
• Pacific/Bougainville: +11
• Pacific/Efate +11
• Pacific/Guadalcanal: +11
• Pacific/Kosrae: +11
• Pacific/Norfolk: +11
• Pacific/Noumea: +11
• Pacific/Pohnpei: +11
• Pacific/Auckland: +12
• Pacific/Fiji: +12
• Pacific/Funafuti: +12
• Pacific/Kwajalein: +12
• Pacific/Majuro: +12
• Pacific/Nauru: +12
• Pacific/Tarawa: +12
• Pacific/Wake: +12
• Pacific/Wallis: +12
• Pacific/Chatham: +12:45
• Pacific/Apia: +13
• Pacific/Fakaofo: +13
• Pacific/Kanton: +13
• Pacific/Tongatapu: +13
• Pacific/Kiritimati: +14

Note: Linux displays correct time for Easter Island.  IOS was off by 1 hour.

Note: Pacific/Samoa means American Samoa, as WS is +13 not -11.

We are currently on -9.  There are no entries in the above list on -7, but somewhere in North America would do for that.

For reference, here are a couple of others from America:

• America/Anchorage: -8
• America/Vancouver: -7
• America/Mexico_City: -6

Back to the ship: have set Linux to Pacific/Gambier.

On MacOS, it doesn't come up in the GUI, but some research reveals that it does have it at Unix level.

AI suggestion of "sudo systemsetup -settimezone Pacific/Gambier" didn't work as systemsetup didn't recognise it.  

Next suggestion was symlink identical to on linux.  This does work for time in terminal.  Apple's clock in top-right is stuck on some other time and won't budge.

Have also discovered the Etc/ zones have the fixed offsets like those I suggested above.  The AI says the plus and minus signs are reversed in a POSIX quirk.  So the AI says:

  sudo systemsetup -settimezone Etc/GMT+9

would do it.  But this set the Apple clock 9 hours forward and the system seemed confused about time afterwards.

Same with Pacific/Gambier.  UTC is Wednesday 21:44. Terminal shows 12:44, correct, and shows correct offset.  Apple clock shows Wednesday 21:44, so it's showing UTC.  Okay.  I guess that's what it does if the timezone isn't in the Apple GUI subset list.

More research reveals there is no nice way to get MacOS clock to display the time correctly when on UTC-9.  The AI suggested some insane stuff like choosing a bogus location, then killing the network time daemon, then setting the clock, or something.  It didn't amount to selecting a timezone that gives the correct offset for the ship's time of -9.  It changes on to -10 tomorrow night, which should be fine.

When it comes to iOS, there is no way to do this, and even the AI admits this.