So you want to abolish time zones (2015)
qntm.org
qntm.org
This article was written in 2015, when it was already extremely easy to search "What time does the work day start in Australia?". It's only gotten easier and easier as search engines implement smart widgets, of course, but even then it was not at all the medieval process described. (Finding a webcam in the city? As clever as it is stupid.)
> "It would be neat if there was a lookup table for that kind of thing."
There is now and always would be without timezones. Abolishing timezones doesn't mean people stop caring about time.
Probably just about anything you want, as is already commonly available.
Mostly, I expect nations would have official business hours for public employees which would be easily searchable if you needed to call someone on another side of the world, which is not any more difficult than looking up what time zone they live in is now.
Sunrise/sunset doesn't really give you much of an idea for those, (as you move aware from the equator, at least)
I think it's becoming more and more expected to send a "hey is this a good time for a phone call" before calling.
I think the move away from landlines to mobiles is increasing that expectation further too.
If they don't want to be woken up in the middle of the night you turn on do not disturb on your phone (and most phones let you exempt specific contacts from DnD, or a 2nd call from the same number)
Eight billion time zones, all available at a glance, with their contact info — Yay!
(I'm not sure myself if this is real or sarcasm, but if it was all UTC, it sure would be one good convenience for caller and callee)
The problem we have today is that we have mass confusion as to when common events like meetings are. In a distributed society like ours, it doesn't matter if I wake up at 04:00 or 17:00 but it does matter when the basketball game is or the meeting is or when the company in Lebanon starts.
The constraints of our society have changed. People in India work the hours in London. People in Florida work the hours of California, and vice versa.
And as we see, we already have countries that span four "natural" time zones and Western China has some ability to adjust.
In the context of the webpage where that is quoted, it means looking up the typical activity for the time in that location. By avoiding the look up of time zones, you haven't really reduced complexity and only shifted it somewhere else because now you're looking up relevant "activity" windows for that location.
You always have 2 components of a key-value dictionary in either system. (1) the "fixed" a familiar knowledge you have as a "key" and then (2) the lookup "value"
- Timezones system: (1) fixed knowledge key is "I know people are awake doing school & business between ~8am to ~5pm and sleep ~9pm to ~6am" for entire globe --> (2) now lookup what timezone they're in : e.g. "California TZ is UTC-07:00"
- no timezones : (1) I know the entire globe is on identical time --> (2) now lookup what numerical values correspond to "awake vs sleep time" in that part of the globe : e.g. "California school/business hours are ~3pm-12am UTC"
Today, if you need to contact a business in Brisbane, you start by looking up their hours, then you convert timezones, then you plan your contact
Without timezones, you no longer need the second step.
Similarly if you are planning a meeting with someone in Brisban you can just say "Does tomorrow between 4 and 8 work for you", with no timezones involved
Honestly seems like an obvious advantage to me
So far, I used to think that people were joking when they advocated abolishing timezones. Now that it seems some are actually serious, then I have a serious question - how do you plan to convince the local population to adopt a completely new time?
For example, I am in SFBA and if there is a vote to shift our time by 8hrs to align with UTC (global timezone), I would vote no. I don't see any benefit in shifting my day by 8hrs and instead of sleeping from 10 to 6, start sleeping from 6 to 2. Oh wait, or would it be 2 to 10? Ah nevermind, too complicated. Let's just continue my current lifestyle because the cost of switch is too high for no obvious benefit to me.
It would feel weird for a while for people no doubt but times already are arbitrary anyways. Why does it matter if you sleep from 1-9 or 13-21?
No it would still be a tremendous hassle. I have a much larger life than my phone, computer and boss. Like, kids - explaining to them the new time change and teaching a whole new schedule ("start bedtime routine at 4:30 instead of 8:30pm") alone would make me vote against this change.
> Why does it matter if you sleep from 1-9 or 13-21?
Because you haven't told me what's the benefit if I do that.
But you're still correct: When most people are using time in conversation, they need it to be meaningful with respect to solar time. If your replacement method can't do that, no one will adopt it.
No imagine replacing this step with 'is now a good time to call someone in Australia?' or 'what local times of mine are good to call someone in Australia?'. You can have a tool/app/algo which accounts for the differences in daylight, cultural differences in working hours, holidays etc and just tells you what a good time is.
The biggest advantage of getting rid of timezones is when an absolute point in time is mentioned, e.g. the start of an event. It's so annoying when the start date for some global event is announced and they only include a local time in some obscure timezone.
If you're going to live-stream an event for the whole planet to see, use UTC. It's especially baffling that organisations such as SpaceX or NASA use local time instead of UTC. You'd think that anyone dealing with things in orbit would use UTC.
Source: every discussion I've ever had about how to deal with storing dates in databases, date comparisons, etc
If Timezones are difficult for programmers to model into our systems, then they are likely difficult for everyone to model in their brains
Simplifying the model benefits everyone, not just programmers
"what time is my colleague available" and "what time is that in my timezone"
With just the first one
If time zones where abolished you do t have to worry about what time zone a written time is in (is the 7 eastern or central or GMT or etc) its always 7 UTC.
Then you can take the SAME knowledge that East Coast of the US is 6 hours behind UTC, to figure out that 13:00 is the morning for them.
> causes the question "What time is it there?" to be useless/unanswerable necessitates significant changes to the way in which normal people talk about time
This is a significant benefit actually. The answer to the question would be: It's exactly the same time everywhere.
> convolutes timetables, where present
If convolute means simplify then agreed. Flights would no longer sometimes arrive yesterday or go back in time. Sure the position of the sun might be different at your destination but you can be assured that you will not land in the past.
> means "days" are no longer the same as "days"
Fair criticism but already days are not days. If a team on the other side of the globe tells you they will get it done today, are they referring to your time zone or theirs? This is easily solved by simply saying "I will get it done by 0500 (utc)" which is more precise and probably better anyway.
> complicates both secular and religious law
It's already complicated. When does fasting end if you live in the artic circle for example? It's easy enough to map the solar day onto the utc time. Sunrise and sunset fluctuate anyway based on latitude, longitude, local laws, and even terrain.
> is a staggering inconvenience for a minimum of five billion people
Why?
> makes it near-impossible to reason about time in other parts of the world
You already need to consider the offset to your local time, knowing a single offset to UTC rather than having to subtract two offsets is far from near-impossible, it's actually far simpler.
> does not mean everybody gets up at the same time, goes to work at the same time, or goes to bed at the same time
People already don't do this
Is a really bad example, since Australia has 6... or 9, depending how you look at it.
It'd be much easier to just have a single "timestamp" that everyone uses then think about offsets from that.
Yes, the answer is yes, it is.
The most enduring fix is almost always like you said, store timestamps in UTC (plus a zone name string separately, because an offset isn't always enough), plus use standard libs instead of trying to do your own datetime or time zone math, then format timestamps into human readable localized dates as late as possible for the user. In JS that means Luxon or date-fns instead of the woefully inadequate built-in Date methods.
1. Please, please use native datetime objects instead of integers. A bigint (needed to represent datetimes past 2038) is 8 bytes, same as `timestamp`.
2. Please, please store explicit timezone values. Even if they're all UTC and it "feels redundant". `timestamptz` and `timestamp` are both 8 bytes in Postgres.
If you can't articulate the 10x advantage an integer gives you for your particular app (they are vanishingly few in 2024), please, please use `timestamptz`.
thank you <3
Err, maybe you come from Windows?
In all variants of 'nix I'm aware of (and we are going back to the 1980's here), the kernel time is always UTC. You then set your TZ environment variable to reflect whatever timezone you are in.
Why? Well because back in the day we had time sharing as computers were far, far too expensive to be used by just one person. So from day 1 'nix assumed people would be logging in remotely, and when they did "date" had to display the correct time. In fact all time stamps were stored in UTC - including in the inode (eg, file modification times) and of course archive programs like tar used UTC exclusively.
Time moved on, we got PC's, and so the model moved to being one Computer was devoted exclusively for the use of one Person. DOS, and later Windows hark from that era and not surprisingly they too the opportunity to ditch all that UTC conversion complexity and store everything in local time.
But in a bizarre turn of events as computers got even cheaper they became so powerful they could services 100's or 1000's of people at one time, and with the rise of the internet it became cheap to connect them to those people. What's more it became profitable, as mum and dad just didn't want to handle the complexity of managing their own computer systems. Instead they pay someone else to do it. Fair enough I guess, but boggles my mind when youngsters here who evidently class themselves themselves as "computer professionals" say it's far too difficult to maintain computer hardware and systems, it should be left to the experts like AWS and Azure (at 10 fold mark up, thank you very much).
And so here we are, what was old is new again, and you are asking "please can we just store everything in UTC" because everyone shares computers.
Well, we did son. Then you young'ins came along and fucked it up.
I'm normally just doing a mental mapping of when's good to call someone based off my time anyway, and their usual habits — "My brother is normally free to catch up when I get off work at 5pm". Rather than — "My brother is in France and there it's 6pm, therefore it's a good time to call him."
If I don't know, I'll send someone an IM — hey Steve, fancy a call to catch up? I'm free for the next hour or so if your around now. Otherwise I'm free all day Saturday.
The things that have worked for me are:
- Storing dates as dates, not datetimes. Sure, you can make sure you always treat them as local/timezone less, but someone at some point will apply a timezone to them and it will break.
- Integrate pulling the latest zoneinfo as part of your CI.
- Store everything as UTC and use the client’s TZ for rendering.
How to deal with customers changing their timezone is always tricky too. “Do they want this to run at 3PM local, or 3PM of their previous TZ?”…
Even within the same timezone, countries/cultures differ. And even within the same country/culture, people differ.
I'd never call a tech friend at 8am, I might well wake them up. And I'd never call a rancher after 8 - they will be working without cell. 6-7am is ideal they will still be working, but hopefully inside cell range with a cup of coffee.
Before introducing time zones
I want to call my Uncle Steve in Melbourne. When does the evening start there? Google tells me it's 8:00. Better not call right now.
After introducing time zones
I want to call my Uncle Steve in Melbourne. When does the evening start there?
It's 20:00, same as it is here, of course! Same as it is in New York, Bangalore and Hawaii, at the South Pole and on the Moon. Well, hold on a second. First of all, we need to straighten out some terminology. What does 20:00 mean exactly? It's strongly deprecated now, because now it refers to the position of the Sun, not of the clock.
And then it goes on like this for 5 pages...
Imagine we had universal time across the globe and someone tried to introduce time zones. It would seem like a batshit crazy idea to everyone.
So what if my Friday workday spans two dates? Wouldn't "Friday" just be my local day, which spans March 14-15? I feel people like the author would be intentionally making things difficult by referring to local days and absolute dates by the same names without making efforts to differentiate. In reality, language adapts rapidly for convenience in most cases.
From a dev's point of view, timezones in real life are okay and much more annoying in data/software because sometimes, other folks don't care about capturing timezone offsets properly or converting to UTC.
We all just long for clean UTC timestamps that can be created, parsed or passed around without concern until they are displayed and formatted according to a local timezone where ever. Abolishing day time savings would simplify this even more.
I currently have a widget in my calendar dropdown with the timezones of several cities that occasionally need to be tracked for meetings.
Each one has a little clock face, that could show day/night times in other cities. Like this: https://cdn2.vectorstock.com/i/1000x1000/16/61/clock-day-and...
I think iOS used to have it as well. Gnome2/Mate had a fantastic day/night view of the Earth in its calendar widget as well. Didn't seem to make it to the new dumbed-down desktops sadly. I've used xplanet for this too.
Even in the old days, you should have looked it up before placing an international call.
Anyway, you're going to need technology to solve this one way or the other, especially when meeting folks halfway around the world. So everyone using UTC is not an impediment. Just a different way of working, which is the hard part. But not everyone has to change at once. Could be one organization at a time.
Not even saying I'd prefer it, but it is reasonable to try.
Another approach might be infinite time zones, which on a local level is deferential to local customs. For important times (like transactions), UTC still exists. But, for meeting at the pub, church or school a two second difference from your house isn’t meaningful. Probably each regional hub would recognize its own solar noon anyway. So still regional coordination, but smaller regions than 1-timezone China.
If you mean local solar time, you need to realize that changes over short distances. At my latitude, one minute is 9 mi. I have coworkers that commute that far to office so they would have to keep track of home time and office time. Or they would be late to Zoom meetings.
You see, not every event has to specify the exact offset because in practice:
1. If you’ve got coworkers who are a minute late attending a meeting, no one cares. Or, they show up four minutes early instead of five.
2. This level of formality (keeping track of home and office time) is a ruse. A minute here or there is constantly lost or gained with traffic, tasks or luck.
When that precision is needed, I’m sure your calendar + gps on your phone can give you the exact nanosecond you need to join the Zoom.
For humans, time is relative to the individual. When absolute coordination is necessary, computers step in and nudge you along. Turns out they’re good at that.
There are lots of things that are accurate to the minute. If you are a minute late, you miss your bus. Also, what time does the bus use? Does it change time as it moves or keep consistent time?
The coordination basically requires computers. All watches need to have GPS. All computers need to have GPS. Every event requires someone to enter the official time/location. It would be impossible to accurately schedule anything over the phone.
Local solar time wouldn't be for humans but for computers. Humans invented time zones because of the problem with local solar time for railroads. We much prefer consistent time zones for day-to-day.
>At the equator, the position directly underneath the mean Sun travels west at about 463 metres per second. That means a standard [server] rack unit is about one millisecond wide.
I made our launch networked factory stations use UTC, to aid debugging with the various servers involved. (Such simplifications help, especially in debugging and incident response, especially when you don't yet have centralized observability.)
But the first time I had to investigate a problem remotely, on a station at a factory in Asia, the timestamps from various systems weren't lining up. I quickly realized that the station clocks had somehow gotten set to local time there.
Turns out that, when some of our team flew out to install the stations in the high-end factory in Asia, factory personnel noticed that there was a UTC time on screen for a few seconds during station startup, before it finished booting into the fullscreen appliance UI.
Factory personnel were so alarmed by a factory machine with the "wrong" time, that my people on the ground made the decision to change it to local time. (I suspect it was alarming because some other factory machines had operation procedures for personnel to ensure that the time is correct.) And in all the excitement of a successful launch, they forgot to tell me.
Maybe an additional reason against a single time zone: aoption resistance from people who don't understand, or who just like the local time.
For example, I can imagine many people stubbornly using "shadow" time zones for various purposes, and only using the official time zone when required (and this being error-prone).
The problem I meant to highlight was that there can be surprising local resistance to something like UTC time, from people who aren't IT nerds. In this case, resistance to something we didn't even think they'd see during boot. And that prompts thinking about other ways there might be resistance, and what might happen due to resistance.
The people on the ground made a judgment call that this wasn't the thing to communicate harder or spend political capital on, and I support them making that call.
Google tells me it happens at 7:17am. It is currently 4:25am.
It's probably best not to call right now.
Invariably, there is a thread from someone new to the mess that is 'time' that discovers things like leap-seconds or Japanese Imperial Years and is just blown away at the insanity of it all. Then there are discussions on how to implement the logic, with much cursing at Excel. And then someone mentions relativity and everyone just sighs and acknowledges that old Paul Krugman paper.
I used to work in an atomic clock company, so all the issues with 'time' are a bit old hat for me. But it's always a blast (honestly!) to see new people's heads explode in these comments as they slowly realize that 'time' isn't really a thing thing. Like watching chicks hatch.
I don't know who else has looked at a time zone map, but it is a clusterfuck. And that's putting it mildly.
In so many places, you can tell the time zones are set politically, not geographically. Which goes against the entire philosophy of time zones. I should not be able to drive due north/south and change time zones.
I'm not surprised that certain regions in China use a local time as opposed to their "official" time zone.
I also think that's a lot of the reason behind the resistance to standard time year round. Some people live in areas that are geographically in the wrong time zone, so their solar time is already fucked.
I think the article is way too negative about something that’s easily solvable with no more effort than what is required today to keep track of someone’s time zone and DST.
His points are based on conventions that exist because we use local time zones and he uses a lot of English centric bias in his argument.
His first point of am/pm is already a bad start considering a 24h clock is simply advantageous and used throughout most of the world.
Finding out if he can call his uncle would be as easy as looking up daylight times instead of time offsets/local times. And even then the cultural conventions of your country might not map to his and it was still inappropriate to call.
The problem with business hours and overlapping days is entirely made up, because he wants to stick to previous conventions that worked well with local time. If a night club opens Saturday from 19:00 to 05:00 it's perfectly clear that means it's open till Sunday 05:00. It would work similarly for business hours. The regular business hours also differ vastly in different cultures and jobs! The day name is of course UTC based and wraps at 00:00UTC.
I play an international online game that wraps days at 00:00UTC and we communicate in UTC. If I say Wednesday 14:00 UTC it's perfectly clear what that means and you get used to that very quickly. If we would change the system the next generation would grow up with that system and it would be natural. And I find it much easier to remember that my Korean friends are available from 23:00 UTC till 16:00 UTC than to remember what time it is there right now compared to here, because that requires mental math or a lookup.
Some longitudes would probably wind up more sparsely populated than others, but the world's large population of night owls would finally be able to truly coexist with...you lot
> Each day in the Republican Calendar was divided into ten hours, each hour into 100 decimal minutes, and each decimal minute into 100 decimal seconds.
> The month is divided into three décades or "weeks" of ten days each, named simply:
primidi (first day)
duodi (second day)
tridi (third day)
quartidi (fourth day)
quintidi (fifth day)
sextidi (sixth day)
septidi (seventh day)
octidi (eighth day)
nonidi (ninth day)
décadi (tenth day)
Not exactly a success story, although ancient Egypt seemed to have some success.
I don't think non-decimal is at the root of the issue.
I also forgot to motion timezones, leap seconds and leap years...
Attempting to build decimal parts fundamentally results in ~36.5 deci-days. Assuming we extract the non-integer part with intercalary days, we are still left with 36 deci-days which has a prime factorization of 2*2*3*3, so you can choose 2:18, 3:12, 4:9, 6:6. Might as well choose 3:12 since it is closest to the current system. I guess 9:4 might also be reasonable to denote entire seasons.
You also did not include the Sun in your list which is a fairly big oversight if you meant to do away with the current solar day and year given the Sun is the dominant temporal determinant of our existing calendar system. You excluded the thing that gives the calendar its name. Getting rid of the (Sun and Moon) or (Sun, Earth, and Moon) would have been clearer than the ambiguous (Earth and Moon).
If we remove everything cosmic then we might as well do away entirely with ymd terms. kilosec, megasec, or whatever.
But! Removing the sun makes it immediately extremely impractical for scheduling: to schedule anything you'd have to constantly refer to an almanac - however rough - of the sun's position as, being completely removed from the sun and the biological constraints of circadian rhythm, time tracking will inevitably drift and offset to the point that it's impossible to reliably ensure actual people will be available for an appointment in 10ksec or 20Msec - whatever these secs are - in any intuitive or sensible manner that maps to the way biological beings fundamentally function, both at the solar day level (very fundamentally so) and the solar year level (less perceptible than day-level but still fundamental).
I mean, if I ask you what were you doing at 1610403576 unixsec or are you available at 1810403572 unixsec it is impossible to answer if you're even going to be sleeping well into the night without looking a sec-sun table (an almanac) up. The fact that unixsec as a duration is our current sec is immaterial - it could be anything so it might just as well be that one - as we just decided we're entirely removing the sun from the equation and defining secs in terms of fractional days would run against that. "well, I'll be sleeping" is the most common "not available" situation that we all share for ~1/3 of a day, everyday. Not exactly a corner case.
Consider that shops would not even be able to have "opening hours / days" signs on their door! Or dropping kids at school, setting an alarm clock, planning a trip to arrive at dinner... There's so much implicit scheduling around us that we're fixated on the comparatively small times where we have to open a calendar app (and even smaller when we have to cross timezones but that's not the topic of this specific thread). "I'm using a calendar already so everything might just as well be in the calendar" just doesn't stand up to the real world.
Since it's so impractical it follows that the only reasonable base unit of measure is not an arbitrary second† but the sun-bound day. The same argument can be run down for the four-beat-seasoned solar year, which allows us to intuitively grasp and anticipate so many things and organise as a civilisation - even when technology fails on us - that we take them for granted. And then, from that, we end up with a calendar shaped one way or another like the French Republican one.
† Even that could be challenged as our hearts beat at a rough ~1 beat/s at rest so there's a deeply grokked biological sense of time for us tied to that duration: 20s kind of resonates and that duration can be felt. Make the second half or twice and it's lost.
That being said all that matters when making a call is the availability of each party to the call. If one of them is sleeping at that time then they are clearly not available.
So, if you want to abolish time zones all you need to do is:
1. Use a 24 hour clock instead of a 12 hour clock. Stupid easy.
2. When making phone calls know the availability of people you are calling. You should be doing this anyways, but maybe you’re an asshole and consideration of others becomes an insurmountable impossibility.
3. Take some personal responsibility to know when there is and isn’t sunlight hours for your current geographical location.
That it. All further challenges come from stupidity and those challenges will remain regardless.
If only the idiots in charge would accept my brilliance.
Sunrise in Glasgow if the U.K. was on UTC+1 year round would be as late as 0945 in December, civil twilight wouldn’t start until an hour after people leave for school.
Before the 1800s the day began when the sun came up, this varied every day. Clipping this to specific hour is far more sensible for a global community.
See (variable-length/unequal) temporal hours:
> Adapting the European clock designs to the needs of Japanese traditional timekeeping presented a challenge to Japanese clockmakers. Japanese traditional timekeeping practices required the use of unequal time units: six daytime units from local sunrise to local sunset, and six night-time units from sunset to sunrise.
> As such, Japanese timekeepers varied with the seasons; the daylight hours were longer in summer and shorter in winter, with the opposite at night. European mechanical clocks were, by contrast, set up to tell equal hours that did not vary with the seasons.
* https://en.wikipedia.org/wiki/Japanese_clock#Temporal_hours
In brief, our bodies evolved in the the movement of the sun, not numbers on a clock, so called solar time. Standard time aligns the numbers on the clock the best with solar time for most all of the world. There are some exceptions along the equator and at the poles at different times of year, but those are exceptions that have been, and can continue to be, handled well by people in those areas.
Or we could simply change the common time everyone uses and not have to reprint everything.
Summer "daylight time" tweaks that by an hour (or two?) in order to make customary "waking-up time" closer to the summer sunrise.
Permanent daylight time just shifts everything over one timezone to the east, which to me seems kind of silly (along the lines of the "these go to 11" bit in Spinal Tap) but does have the benefit of not having to rename things like "the 11 o'clock news".
There is a way to do that, it's called summer time.
Your kids will grow up quickly and you could change jobs over a year or two if it is particularly inflexible. Whatever your situation, it is a short period of your life that can and will change.
A time system doesn't have to solve everyone's problems, in fact it couldn't if it wanted to. Basically the point is to solve your own problems as you see fit, not push one solution onto everyone else.
We _should_ abolish DST. The issue is that there are people who want to abolish Standard Time because, I don't know, they have weird notions about how awesome it is to have the sun up at 8pm. Or don't understand that there are just fewer hours of sunlight in the winter in general. Yeah, it's going to get dark earlier, it's a thing that happens every year. It's better to have early morning sun than late evening sun.
And the last time we tried abolishing standard time, everyone hated it and we went back to switching between daylight and standard. But places that abolish daylight savings time never go back.
It's a case where people are particularly stubborn about wanting to validate their feelings rather than do the thing that would actually work. Because people bitch and bitch about standard time in the winter and think they're bitching about the time system. When really, they're just bitching about it being winter, but they don't realize that.
Is there actual data backing that up or just your opinion?
I personally really enjoy more hours of sun in the afternoon and early evening. As an office worker most of my mornings are just waking up and getting ready for work, not normally lots of time for recreation. Having more hours of light later in the day aligns with my free time hours better.
There is data backing up that early morning sun is better. It being light out when kids go to school and when we drive to work is more important. There are also things about our circadian rhythms and what not.
The "more hours of sun" is only an issue in the winter. In the summer/spring/fall, the sun goes down at reasonable enough times for you to still do all of your recreation. But in the winter, the sun is going to go down earlier anyway. And what sort of after-work recreation are you doing that requires the sun to be out?
Easy. Without time zones, you post the hours (UTC) when you're available. You refuse to answer the phone outside those hours. UTC makes this easy!
- why do you not already know the relevant times of your activity memorized in UTC, including of your distant friends, family, and business partners?
This system exits, if you care for it, and if it actually makes sense in your context.
Most eggheads, including many senior engineers, will think for a bit and eventually say no. It's beyond dogma at this point that storing localtime is bad mmmkay.
The one exception I've encountered (I suppose there could be others) is when the value is to be used for recurring event scheduling and you need it to happen at a certain time locally. For example, this event should fire at 1am Central Time every other Tuesday morning. Since "Central Time" obeys Daylight Savings, the time component of the UTC representation of "1am" will lose and gain back an hour as the months of the year go by. So instead you would store "1am Central Time" as the scheduled time and fire the job whenever it's currently 1am Central Time.
** If I've overlooked a way to accomplish this with UTC, I'm all ears. I suppose you could have a job that predicts upcoming event fire times and stores them as UTC. For example, "next fire time" could be generated right after the event fires, as the UTC representation of 1am Central Time two Tuesdays from now.
There is a distinction between timestamps, for exact moments, and event times, for future local times. The former should be stored in UTC, and the latter in local times.
Yes, it would eliminate jet lag from flying thousands of kilometers in an east/west direction. /s
My grammar teach would have comments. "Why are you unable to call him? Are you physically unable? Is the phone not working?" Of course you can call, it's more of a good question on how convenient it is for the uncle to receive your call.
I hated those teachers. Okay, hated is a strong word, but I really liked them much less after banging on such stupid method of teaching. I'm clearly affected by it to this day