10 ms·
This is why no one should ever ever write their own Time or Date library. The number of edge cases is simply enormous
by hmate9 7y ago
This is why no one should ever ever write their own Time or Date library. The number of edge cases is simply enormous
- velox_io 7y agoAsk Jon Skeet: https://blog.nodatime.org/2011/08/what-wrong-with-datetime-anyway.html https://blog.nodatime.org/2011/08/what-wrong-with-datetime-a...
- hyperpape 7y agoWhen you encounter someone saying "no one should ever", you can substitute "fewer than a half dozen groups of people should tackle this problem (in systems they want to use in production). It will take each such group a tremendous number of hours, involving a multi-year process of slowly finding edge cases and missing functionality." If that's not true, then there's room to complain, but dates and times fit the bill. In some ways they're worse than other "harder" problems, because people are more likely to think those harder problems are too hard for them. And while the vast majority of companies don't need a proprietary database, it's more likely to be a competitive advantage than your own datetime library. I think I could eventually write a good datetime library. But I certainly should not, unless I decide that's going to be one of my major efforts to help a language that doesn't already have one.
- maxerickson 7y agoWhat if people tried to speak precisely for effect instead of hyperbolically for emphasis?
- jrandm 7y agoI believe accurately conveying identical information in a manner everyone can understand is an impossible, or at least unreasonable, burden to place on individuals. Instead, what if people tried to hear graciously and "assume good faith"? The quote is ripped from HN's guidelines.
- maxerickson 7y agoCan you please explain more about how your response relates to my comment? For instance, I've not placed the burden of "conveying identical information in a manner everyone can understand" on anyone, nor have I assumed bad faith. So it seems like a weird comment to tack onto mine, but I am assuming I just don't correctly understand.
- IggleSniggle 7y agoHyperbole and precision can get tricky in human language because different cultural groups have different language encodings for the same sets of words. For example, if you live in London then "9 in the morning" means when the world synchronized clocks agree that, locally for you, the time is 9am. But if you say "9 in the morning" to someone in Belize, it means "first thing after you are finished with your morning and ready to start your day," which can mean 1pm in some cases. Here's a lovely article on these kind of time-keeping differences, around something that you might expect to have a precise meaning: https://www.businessinsider.com/how-different-cultures-understand-time-2014-5?op=1 https://www.businessinsider.com/how-different-cultures-under... More to the point at hand, however, you suggested that people not speak in hyperbole but instead speak accurately. Although you can request that others adjust their use of language while in your presence to better meet your needs for a certain kind of precision, policing other people's language isn't possible. However, re-interpreting what people say into what they mean is somewhat possible for an astute listener who understands the context.
- maxerickson 7y agoYou are making my simple statement really complicated. I'm not walking around demanding people change their communication to accommodate me, I'm suggesting that trying to speak precisely can be a useful exercise.
- IggleSniggle 7y agoI assumed you were being precise when you asked "why can't people speak more precisely" and also when you asked "can you explain how your comment relates to mine?" I am not the person you originally responded to, fwiw, and I agree that trying to speak precisely is a useful exercise, even if I believe it is impossible except in highly formalized languages.
- wwweston 7y agoPrecision of understanding would go up and emotional investment in a topic would likely be more proportional to true stakes? Sounds boring but functional.
- 76543210 7y agoHow about C rtos? How should that be handled?
- Misdicorl 7y agoAlmost all the edge cases with time have to do with localization. Build your time library on (un)signed 64 bit integers representing the number of nanoseconds since the utc epoch. Adjust above sentence to reflect the level of precision and range your use case needs. You are now done for 80% of use cases (perf timing, logging, timeouts, event storage, event ordering within jitter). If you need to parse/display for humans or have something happen at a particular time in a particular timezone, things get gross. But that's no different than any other situation where you eventually have to interface machine data with humans. Either it's your particular expertise or it's a distraction and you should use someone else's solution.
- burfog 7y agoYou can still have problems. It may be determined that the computer's clock got too far ahead. For example, it booted and you cared about time, but NTP hadn't yet made corrections. Suddenly the time runs backwards. Leap seconds may get interesting too, especially if you have to predict ahead or if the OS isn't updated often enough. (there is a 6-month warning) If you want to call leap seconds an issue for humans, then you aren't using UTC at all. You're using TAI. Software interfaces often ignore the distinction between UTC and TAI, and even between UTC and UT1, preferring to pretend these issues don't exist. POSIX is in conflict with international timekeeping, effectively requiring that there are zero leap seconds.
- Misdicorl 7y agoLeap seconds are only a problem for wall clocks (localization) and deciding whether to call something utc or tai. The ntp case is contrived. Either you care and wait until ntp has connected to do your stuff. Or you care and don't let ntp rewind and instead smear. Or you don't care and deal with the consequences.
- mortehu 7y agoLeap seconds affect Unix time too, because leap seconds are excluded from "number of seconds since Unix epoch". You can't measure the length of time intervals spanning leap seconds with simple subtraction.
- ehsankia 7y agoIt's not only about writing your own library though. For example, it's often not reading the documentation properly. In Python, if you take a datetime, and call .replace(year=X) on a datetime for Feb29, it'll throw a ValueError.
- Aeolun 7y agoEven if you replace it with another leap year?
- cgriswald 7y agoIt returns a new datetime object which includes its own validity check and raises an exception for a bad leap day the same way it would for March 32nd or Blurnsuary 12th. (However, year must be an integer in [1, 9999].) Edit: So, another leap year would be fine.
- ehsankia 7y agoNo another leap year would be fine. But yeah a very common (wrong) pattern is, if you want to find the same day a year in advance, is to do `d.replace(year=d.year + 1)`, and that would break on Feb 29 only, so one day every 4 years. It's a very common pattern unfortunately.
- perl4ever 7y agoWhat if you take March 31st and add one month to it? (I assume you can do that somehow)
- deathanatos 7y agoNot with the standard library. (The "timedelta" class only expresses in units up to days, as it is ambiguous how long a month is. There's a nice package called "python-dateutil" that includes a "relativedelta" class; adding a month to March 31 results in April 30: In [7]: datetime.datetime(2020, 3, 31) + dateutil.relativedelta.relativedelta(months=1) Out[7]: datetime.datetime(2020, 4, 30, 0, 0) Adding a year to a leap day: In [8]: datetime.datetime(2020, 2, 29) + dateutil.relativedelta.relativedelta(years=1) Out[8]: datetime.datetime(2021, 2, 28, 0, 0) The exact duration that relativedelta adds depends on what you add it to. (Hence the name.) But the results tend to match up with human expectations.
- PopeDotNinja 7y agoImmediately thought of Tom Scott's Computerphile video on time & timezones: https://youtu.be/-5wpm-gesOY https://youtu.be/-5wpm-gesOY 10m12s watch. Informative and entertaining.