81–90 of 333 posts
Earlier quoted context omitted.
Those ISO-8601 dates are great for date processing with primitive tools such as GNU sort or awk since they sort lexically, at least if you're not comparing dates in different time zones.
ISO 8601 is the way .
Earlier quoted context omitted.
I like how Temporal[0] does this. What you were dealing with is Temporal.PlainDate[1], i.e. a date with a calendar associated but no time or timezone (might be due to being implied but also might be irrelevant, like in birthdates). Temporal has other cool types, each with distinct semantics: - Instant: a fixed point in time with no calendar or location. Think e.g. "the user logged in at X date and time" but valid acr…
yeah, it was a long (and painful) time coming, but i think the temporal api finally basically nailed it. you know a library is good when you learn something about how to think about the problem just from how the code/api is structured.
No other programming concept has caused me more grief than dealing with time and timezones. It starts to get really mind-bendingly complex once you start thinking about it deeply. That is even before you start encountering the quirks (some places have timezone changes that depend not only on the time of year but also on the actual year). Lesson learnt - choose a library (moment is great) and never think about time ag…
It's like that joke someone posted on Twitter: "I was in favor of space exploration until I realized what it would mean for date/time libraries"
It's funny to reason why we must go to bed when the clock has a certain number, since modern technology could easily be programmed to adjust as needed. No technical reasons the Martians can't go to bed at 9:00am today and 9:40am tomorrow. This mirrors my thoughts on why farmers caring about daylight savings time is farcical, farmers I know use the timekeeping of "crack of dawn" and "sunset".
Likewise Daylight savings is a concept that had its uses, but makes less sense as technology progresses. I don't think even farmers care much about 7AM approximating to sunrise and 6PM as sunset.
Earlier quoted context omitted.
A second is still originally defined as 1/86400 of an Earth day. That doesn't make it unusable as a cross galactic time unit, and I think the same goes for years and hours.
Seconds are now (in SI) defined as calculated from behavior of cesium-133 atoms. https://en.wikipedia.org/wiki/Caesium_standard
I don't think that helps with the original concern.
Multiple times in my career I've had a good laugh when a non-technical manager says something along the lines of "it's just the date, how hard can it be?"
Add phone numbers, email addresses and human names to the list.
Honestly, sometimes I think about the linear algebra, AI, or robotics I learned in school and get this feeling of, "Is this what I'm doing? Stuff that feels like it should be simple?"
It's funny, even our product manager - who is a great guy - can fall into that "come on, this should be easy" mode, and I'll admit I sometimes get lulled into it too. But to his credit, every time I walk him through the actual edge cases, he totally gets it and admits it's easy to forget the on-the-ground complexity when you're in 'planning mode'.
So yeah, seeing your comment is incredibly validating.
It's like that joke someone posted on Twitter: "I was in favor of space exploration until I realized what it would mean for date/time libraries"
It's funny to reason why we must go to bed when the clock has a certain number, since modern technology could easily be programmed to adjust as needed. No technical reasons the Martians can't go to bed at 9:00am today and 9:40am tomorrow. This mirrors my thoughts on why farmers caring about daylight savings time is farcical, farmers I know use the timekeeping of "crack of dawn" and "sunset".
No other programming concept has caused me more grief than dealing with time and timezones. It starts to get really mind-bendingly complex once you start thinking about it deeply. That is even before you start encountering the quirks (some places have timezone changes that depend not only on the time of year but also on the actual year). Lesson learnt - choose a library (moment is great) and never think about time ag…
Earlier quoted context omitted.
A second is still originally defined as 1/86400 of an Earth day. That doesn't make it unusable as a cross galactic time unit, and I think the same goes for years and hours.
Seconds are now (in SI) defined as calculated from behavior of cesium-133 atoms. https://en.wikipedia.org/wiki/Caesium_standard
Earlier quoted context omitted.
Seconds are now (in SI) defined as calculated from behavior of cesium-133 atoms. https://en.wikipedia.org/wiki/Caesium_standard
You can also define "days" and "years" in terms of that SI definition. I don't think that helps with the original concern.
"Our dates start x trillion rotations of pulsar y ago and our unit is defined as z wiggles of cesium" is a starting point.