7 ms·

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 rea

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.

deleted 2y ago
[deleted]
Swizec 2y ago
> 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.
- dotancohen 2y ago
  Please share!
pchristensen 2y ago
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.
- sandblast 2y ago
  Would you be so kind to share some insights?
  - runroader 2y ago
    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
  - pchristensen 2y ago
    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.
lelandbatey 2y ago
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.
riwsky 2y ago
It took Java two tries to get their chronology standard libraries right, but eventually they did: https://docs.oracle.com/javase/8/docs/api/java/time/LocalTime.html https://docs.oracle.com/javase/8/docs/api/java/time/LocalTim...
lxgr 2y ago
> 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). [1] https://gbdev.io/pandocs/MBC3.html#the-clock-counter-registers https://gbdev.io/pandocs/MBC3.html#the-clock-counter-registe...
- somat 2y ago
  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. https://www.youtube.com/watch?v=pr6HTiWrMmk https://www.youtube.com/watch?v=pr6HTiWrMmk (CuriousMarc)
TJSomething 2y ago
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.
zokier 2y ago
Temporal has "PlainTime" https://tc39.es/proposal-temporal/docs/plaintime.html https://tc39.es/proposal-temporal/docs/plaintime.html > A Temporal.PlainTime represents a wall-clock time, with a precision in nanoseconds, and without any time zone. > Temporal.PlainTime refers to a time with no associated calendar date
marcosdumay 2y ago
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.
martinflack 2y ago
> 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.

deleted 2y ago

[deleted]

Swizec 2y ago

> 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.

dotancohen 2y ago
Please share!

pchristensen 2y ago

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.

sandblast 2y ago
Would you be so kind to share some insights?
- runroader 2y ago
  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
- pchristensen 2y ago
  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.

lelandbatey 2y ago

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.

riwsky 2y ago

It took Java two tries to get their chronology standard libraries right, but eventually they did: https://docs.oracle.com/javase/8/docs/api/java/time/LocalTime.html https://docs.oracle.com/javase/8/docs/api/java/time/LocalTim...

lxgr 2y ago

> 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). [1] https://gbdev.io/pandocs/MBC3.html#the-clock-counter-registers https://gbdev.io/pandocs/MBC3.html#the-clock-counter-registe...

somat 2y ago
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. https://www.youtube.com/watch?v=pr6HTiWrMmk https://www.youtube.com/watch?v=pr6HTiWrMmk (CuriousMarc)

TJSomething 2y ago

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.

zokier 2y ago

Temporal has "PlainTime" https://tc39.es/proposal-temporal/docs/plaintime.html https://tc39.es/proposal-temporal/docs/plaintime.html > A Temporal.PlainTime represents a wall-clock time, with a precision in nanoseconds, and without any time zone. > Temporal.PlainTime refers to a time with no associated calendar date

marcosdumay 2y ago

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.

martinflack 2y ago

> 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.