One glaring omission from many tools for modeling chronology is that we have date, and datetime, but often don't have a type for just "time".
Sometimes you really just want to express that something is going to happen at a certain time, regardless of timezone. If I set my alarm for 7:45 am, I need it to ring when the clock says 7:45 am, wherever in the world I happen to be.
This is how most human beings think about time - school starts at 8 am, work starts at 9 am, McDonald's serves breakfast until 10 am, my doctor's appointment is at 4pm... these are all things that remain constant regardless of whether daylight savings time starts or ends, whether our business changes locations to a different state, whether we are conquered by the Romans and our calendar changes... so they should be stored as such, without a timezone attached.
Then from there you can combine a "date" and a "time" and a "location / timezone" to form a "datetime", to figure out the actual technological instant something needs to happen, based on the user's location and/or the location the event is going to take place.
> Sometimes you really just want to express that something is going to happen at a certain time, regardless of timezone. If I set my alarm for 7:45 am, I need it to ring when the clock says 7:45 am, wherever in the world I happen to be.
One of my toughest engineering projects was a system that supports “every Thursday at 3pm” and the participants can be in different timezones with different DST rules. I learned more about time math and how humans think about this stuff than I ever cared to know.
I wrote a library ClockTime at my current job to do this. It's a thin wrapper around a "hh:mm" string for a 24 hour time and a time zone name, with some helpers.
We ran into problems like "someone in Chicago is meeting with someone in Arizona at 10am every day." Worked great until daylight savings time, which Arizona does not observe.
I've learned way more about how to think about, represent, communicate, store, and translate times than I ever thought was possible, but there are tons of war stories of people who have climbed higher on these Mountains of Madness than I can see through the fog of war.
I've climbed this mountain of madness trying to calculate working hours elapsed before. It was easily the project I messed up on more than any other in my career. I'm glad I did it, I'm glad I learned a lot, and I hope to never have to work on something like that again. I'd rather spend the rest of my career untangling double & triple encoded character set problems.
The biggest problem is that if even programmers - who know this is hard, and has a lot of corner cases - mess it up, expect your requirements to be very very wrong with regards to special cases.
Come up with a list of example cases and ask what the expected output should be; but not just the corner cases, the normal examples too. There's a good chance even basic requirements regarding timezone conversions have not been thought about, or are wrong. Like the earlier post said, humans really only think in local time and for short periods in the future or past. Any conversion whatsoever can end up being pretty unintuitive (even if it's right).
If it has to do with scheduling, BE EXPLICIT. Show both (or more) local times and dates and let the user pick a time for either location. Maps with pins can be a very helpful UI affordance
Echoing roadrunner's sibling comment, there's a temptation to translate your time concept into whatever time classes and libraries you are using. This works well for timestamps (a specific date and time, with or without time zone), but trying to make "10:00 am Central time" (no date) fit that just doesn't work. Peoples' interaction with calendars and time is done by sentient beings, so it's much more flexible and sloppier. But you don't have a choice - you have to meet users/business/customers where they are. It's much better to write even a thin wrapper that gives you the interface you need, than try to shoehorn the real world need into an incompatible type.
I tend to judge standard libraries by if they have different types for dates, times, absolute date/times, local date/times, zoned date/times, and time zones. I may have been bitten by time zone bugs a little too often.
> If I set my alarm for 7:45 am, I need it to ring when the clock says 7:45 am, wherever in the world I happen to be.
This property can be surprisingly hard to implement on Unix epoch based systems (just ask Apple), considering time zones, DST and everything!
I wonder if this is the reason that early RTC modules would actually count time in 24 hour or even calendar-based formats, as opposed to a simple binary counter? Examples include some Game Boy cartridges [1], and I believe also Palm OS handhelds (I think they triggered an alarm once per day to recalculate the date, although I can't find a source right now).
Sometimes the realtime clocks were based on watch movements, ok, I only know of one instance, but it is fascinating. these movements were purpose built as a low power embedded device that does one thing well, drive a seven segment display to show the time. so they had to jump through some wild hoops to get it to play with the rest of the system.
So, "time with local time zone"? Tools are normally missing "time with time zone" too.
Personally, I work with a few that are missing "date" too, so at least it's symmetric. But I have no idea why no tooling has support for time data. It's such a common need, it doesn't make sense.
> If I set my alarm for 7:45 am, I need it to ring when the clock says 7:45 am, wherever in the world I happen to be.
Oh I desire more from my alarms.
Ideally I would be able to set an alarm for 7:45am and mark it "all timezones by then-local clock" ... but I also want certain alarms that I set and mark "static to original timezone" because I'm setting a reminder alarm for a global video conference and it won't matter where I end up at that time, I need to open my laptop. ... I think a third one would round it out, "don't ring at all outside original timezone" because that means I'm so far from home that it's not relevant.
Even what you've just described has problems because humans don't think about time in a consistent or logical way that follows real rules that work across different humans in different places. We literally do not think about time in a way that follows rigor or rules, so there cannot be a rigorous computer system which satisfies all the humans involved as it's axiomatically impossible due to being in a world with no axioms! Trying to talk about "time as humans experience it" is like trying to create a definitive list of the "best books of the century"; you can't do it because that's just, like, your opinion man.
If I'm in Portales New Mexico and I drive to see my sibling in Muleshoe Texas at what my clock says is "8:30 AM", that'd take me approximately 40 minutes, allowing me to arrive 9:10AM where I can grab a breakfast sandwich at McDonald's before meeting my sibling for shuffleboard. Except whoops I crossed a timezone discontinuity there, so actually I will arrive at 10:10AM and McDonalds will have decided to stop serving breakfast even though I'm hungry for eggs and the clock in my car happens to read "9:10AM". This isn't some reason to "do away with timezones" because that'd still have the same problem w/r/t travel and different perspectives; if I jet to London from NYC then McDs will also not be serving breakfest when I am hungry for eggs and my (unadjusted since boarding the flight) ticking Timex on my watch reads 9:10am. It's not solvable because people are experiencing different "times" in different places. Either we abolish the concept of time and it's always "whatever number my spiritual essence dictates in this moment via gazing at feeble mechanical devices that I enjoy the aesthetic of" or we swing the other way and all humans record all time in UT1 and we treat the shifting light beyond our windows as a mere inconvenience. We've done the latter with computers because they demand such rigor, implying we'll never do the former and abolish time (it's too useful!), and humans won't all abandon being bound to the sun and its vibes, so here we are in a world where we try to please the fickle and unreliable humans, ourselves, with the cold machinery of our computers (may their flickering lights forever bless us, amen).
Thus, there is only "what's an easy way to represent time that humans won't hate too much?" For most everything, that's "store it in UTC/UT1 and then convert to nearest approximation of what the user wants based factors like 'where are they now?'". Every other approach has pretty big downsides or potential failure modes. For example, if we use the system you just mentioned with a "just time" is "to do anything with it you also have to store enough info to turn it into the other representations". Thus, questions like "how far away is new years eve for my friend across the world?" will be confidently incorrect unless you account for the sun being up here and the sun being down there (typically via the timezone concept). Storing in UT1 at least means you can give the user a time that obeys axioms even if the user has to do a little legwork to adapt their brain to it, which most folks who _depend_ on timekeeping are willing to do to make sure things don't go awry.
I don't see how the problems you mentioned couldn't be solved with storing clock time together with a location (or reading that time together with determining / asking for a location), as was suggested here. Could you share your perspective on that solution?
Because users don't think about "time at a location" and they may not even have a location when they schedule a time. Both parties may say " yeah, meet at 4:30" with the knowledge that it could be my house in DST or your house in MST but we haven't decided yet, we'll figure that out in the future, but it'll be at 4:30.
That's a time outside of a location which works for the humans involved but which is completely unresolvable by the "time at a location" computer paradigm.
People do stuff like this all the time and don't think about it and it's unresolvable and not consistent.
Off the top of my head; the user books a meeting at 2:30am, but local gov decides to implement a timezone change - time moves forward an hour at 2am. Does your meeting still exist?
The software catches the problem during a search triggered by tzdata change, alerts the user and asks for clarification. Before user action, the meeting is considered to be scheduled to 3 AM. Is that scenario unreasonable?
Sometimes you really just want to express that something is going to happen at a certain time, regardless of timezone. If I set my alarm for 7:45 am, I need it to ring when the clock says 7:45 am, wherever in the world I happen to be.
This is how most human beings think about time - school starts at 8 am, work starts at 9 am, McDonald's serves breakfast until 10 am, my doctor's appointment is at 4pm... these are all things that remain constant regardless of whether daylight savings time starts or ends, whether our business changes locations to a different state, whether we are conquered by the Romans and our calendar changes... so they should be stored as such, without a timezone attached.
Then from there you can combine a "date" and a "time" and a "location / timezone" to form a "datetime", to figure out the actual technological instant something needs to happen, based on the user's location and/or the location the event is going to take place.