Similar thing for Names: Falsehoods Programmers Believe About Names https://news.ycombinator.com/item?id=1438472
The Unreasonable Effectiveness of Falsehoods Programmers Believe Considered Harmful
Falsehoods programmers believe about time
111–120 of 212 posts
Re: Falsehoods programmers believe about time
#112When I start at a new company, it's always interesting to see how they handle dates and times. 1) Company A stores timestamps in a mysql database, no timezone, but implicitly on US pacific time. The system timezones are all on pacific. Many weird bugs around DST transitions. 2) Company B stores timestamps in a database as Unix timestamps (ints) Tons of code converting back and forth between ints. Code was a mess. 3) Company C stores them as postgres timestamp with timezone, which was always UTC in production. Code was reasonably sane.
Re: Falsehoods programmers believe about time
#113We should just define a year to be 360 days long and made up of 12 30 day months. Then we can elect some druids or whatever to arbitrarily, at the start of each year, define which dates the seasonal borders will land on. Events which are truly dependent on weather can be defined in terms of "Days after the season starts." Or we could define a 5.5+-.5 day holiday between the beginning and end of a given year. Those da…
Should we also turn off computers in hospitals and in other important facilities? And then how can we qualify what's important? Maybe you and I have the privilege to turn off computers for almost a week without a negative effect, but not the majority of the world, everything uses a computer to operate and coordinate. Think about food production, aviation, shipping, sailing... And much more at both small and big scale…
Ah details, the Time Druids will sort that out probably.
Re: Falsehoods programmers believe about time
#114Earlier quoted context omitted.
Skimming through it I didn’t see my common question of such libraries: can it handle approximate dates? Twice in my career I’ve had to implement code to handle concepts like “August 2022”, or “1pm”, where it was important to track the level of precision offered by the source material for later comparisons. “1pm” is not the same as “1:00:00.000”, nor is “August 2022” the same as “20220801T00:00:00.000Z”.
I think that would be out of scope for the standard library. We do have an interface which might be helpful for developing such a tool, though: https://docs.harelang.org/datetime#builder
Too bad that most stdlibs outscope it to third parties. Wildcard periods are essential for some applications (even as simple as a periodic reminder) and also are hard to do correctly. I’d say a period is actually more important than a date, because we mostly work with periods, and our “datetimes” are just integer coordinates of pixels of time, so to say.
Re: Falsehoods programmers believe about time
#115I don't know if these are all the same falsehoods, but—related: Falsehoods programmers believe about time zones - https://news.ycombinator.com/item?id=24870376 - Oct 2020 (16 comments) Falsehoods programmers believe about time (2017) - https://news.ycombinator.com/item?id=24453712 - Sept 2020 (8 comments) Falsehoods programmers believe about Unix time - https://news.ycombinator.com/item?id=19922062 - May 2019 (268 co…
Should the link be updated to the actual source? This gist appears to just be a copy of https://infiniteundo.com/post/25326999628/falsehoods-program... and https://infiniteundo.com/post/25509354022/more-falsehoods-pr...
https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b...
Re: Falsehoods programmers believe about time
#116I'd like to hear about how to write software orbiting a black hole?
Very carefully indeed
Re: Falsehoods programmers believe about time
#117Re: Falsehoods programmers believe about time
#118> GMT and UTC are the same timezone. I got one for OP, too: UTC is not a timezone in the first place [1]. > UTC is not a time zone, but a time standard that is the basis for civil time and time zones worldwide. This means that no country or territory officially uses UTC as a local time. The difference is subtle, but a standard is not subject to government whims while a timezone is. 1. https://www.timeanddate.com/time…
Still subject to IERS whims, though.
Re: Falsehoods programmers believe about time
#119Similar thing for Names: Falsehoods Programmers Believe About Names https://news.ycombinator.com/item?id=1438472
The Unreasonable Effectiveness of Falsehoods Programmers Believe Considered Harmful https://news.ycombinator.com/item?id=3735928559
Awesome Falsehood - A curated list of falsehoods programmers believe in
Re: Falsehoods programmers believe about time
#120Earlier quoted context omitted.
If you handle dates and times yourself on that level, prepare to be in a world of pain. Handling time and dates correctly has a similar difficulty to writing your own cryptographic primitives: If you don't know exactly what you are doing you will shoot yourself (and potentially countless others) into the foot at one in point or another.
Tbh, half of my life I handled them on a financial platform which couldn’t care less of the subj list or standards. It has just ‘wall date’ like yyyy-mm-dd and ‘wall time’ strictly in 00:00:00-23:59:59 range, without a timezone. Two separate types. Never encountered of even heard of any time-related bug there. I find this simplified date/time very useful, unless you have to manage “continuous and/or real” time someho…
My uninformed guess would be that a financial platform mostly just wants a monotonically increasing clock with which to order transactions. So this would I guess avoid quite a bit of the annoying date related stuff. (?)
Anyway if you queried something to get the current date-time and clock-time, you could be farming out the annoying edge cases to some arbitrarily complicated library, right? Which is the right way to do things.