[HN Gopher] Never write your own date parsing library
___________________________________________________________________
Never write your own date parsing library
Author : ulrischa
Score : 107 points
Date : 2025-07-25 17:36 UTC (5 hours ago)
(HTM) web link (www.zachleat.com)
(TXT) w3m dump (www.zachleat.com)
| QuadmasterXLII wrote:
| I ran into date heck recently in a medical setting for storing
| birthdates. Eventually I settled on the idea that a birthdate
| isn't a physical time, it's just a string. We can force the user
| to enter it in the format 02/18/1993 leading zeroes and all, and
| operations on it other than string equality are invalid. We'll
| see if this survives contact with the enemy but it's already
| going better than storing and reasoning about it as a point or
| interval in time and people's birthdays changing when they move
| timezones.
| kccqzy wrote:
| > people's birthdays changing when they move timezones
|
| That's because the developers use datetimes (aka timestamps) to
| store a single date. Just pick an arbitrary epoch date (such as
| January 1, 1900 as used by Excel, or my favorite January 1,
| 1600 since 1600 is a multiple of 400 making leap year
| calculations even simpler) and store the number of days elapsed
| since then. The rules involving leap years are much much
| simpler than rules involving timezones and timezone databases.
| The translation from/to this representation to a broken-down
| y/m/d takes only ~50 lines of code anyways.
|
| Of course if you don't need to do arithmetic on dates, just
| store three numbers, year, month, and day.
| happytoexplain wrote:
| In my humble opinion, this is not good advice unless you
| demonstrably _need_ it for query performance or something. It
| is very easy for the logic layer to accidentally mess that
| up, either in reading or, worse, in writing back.
|
| In this case, I'd suggest storing what you mean (the user
| wasn't born 9,487 days after Jan 1 1970. They were born Dec
| 23, 1995.)
|
| Storing the literal units (and _ONLY_ the relevant units), as
| the parent has, is robust and logically+semantically correct
| (they could add a translation layer for UX so the user doesn
| 't have to be particular, but that's beside the point).
| Whether you use a string or a struct or some date-only type
| is moot, as long as you're literally storing the year, month,
| and day, and only those three things. You can ephemerally
| convert it to your platform's date type if you need to.
| SoftTalker wrote:
| No, don't do that. Use a date datatype (not date/time). You
| aren't the first person to ever need to handle dates without
| times/timezones in a computer program. Use what your
| database/language/libraries already have to support that.
| tadfisher wrote:
| Specifically, a "local date", codified as LocalDate in
| every date library worth a damn, except for Javascript
| which chose "PlainDate" just to be different.
| PaulHoule wrote:
| Well, for hardcore chronology Julian dates are what you do.
|
| https://en.wikipedia.org/wiki/Julian_day
|
| which are the moral equivalent of Unix timestamps with a
| different offset and multiplier. These work OK for human
| history but will break if you go far enough into the past
| or the future because uncertainty in the earth's rotation
| adds up over time.
|
| If you don't care about timezones timezones may still care
| about you, if you want to minimize trouble it makes sense
| to properly use timezone-aware Zulu (GMT) dates for
| everything if you can.
|
| In certain cases you might be doing data analysis or
| building an operational database for throttling access to
| an API or something and you know there are 16-bits worth of
| days, hours, 5-minute periods or something it can make
| sense to work relative to your own epoch.
| habibur wrote:
| > or my favorite January 1, 1600 since 1600 is a multiple of
| 400
|
| You need to deal with 1600 and 2000 being leap year.
|
| While 1700, 1800, 1900 not being a leap year.
|
| I limit dates from 1900 to 2100. All !year%4 = leap year.
|
| Especially when you try to convert int_date to y,m,d things
| get tricky.
| jerf wrote:
| "Years are not leap years, unless % 4, unless % 100, unless
| % 400."
|
| It's a wacky rule for sure.
|
| 2000 was fun. Everyone knows about "unless % 4", but there
| was also an interesting and very vocal set of people who
| knew about the "unless % 100" but somehow knew that without
| knowing about the "unless % 400" part. A very _specific_
| level of knowledge.
| kccqzy wrote:
| That's exactly why I propose a multiple of 400, not a
| multiple of 100. The proleptic Gregorian cycle is a
| 400-year cycle. There are 97 leap years in it. What's
| tricky about it? Just take a look at my code: https://githu
| b.com/kccqzy/smartcal/blob/9cfddf7e85c2c65aa6de...
| pavel_lishin wrote:
| > _The translation from /to this representation to a broken-
| down y/m/d takes only ~50 lines of code anyways._
|
| Didn't the article explicitly tell us not to write our own
| date parsing library?
| kccqzy wrote:
| I disagree with that. And furthermore it's not parsing.
| It's converting between a single integer and a tuple of
| three integers.
| dlachausse wrote:
| Even better, just make the user input dates using a calendar
| date picker widget instead of a text field. This gives you full
| control of the input.
| Tyr42 wrote:
| I've had to click back once per year old I am sometimes. I'd
| rather just type my birthday.
| mattkrause wrote:
| I always find that a little annoying: it takes way too many
| clicks (esp. for a birth year) and then you've got to find
| the day of the week.
|
| I'd hate it less if typing updated the widget.
| 8organicbits wrote:
| > in the format 02/18/1993
|
| Is this DD/MM/YYYY or MM/DD/YYYY? I can tell from the 18 that
| it's the latter, but that convention isn't universal. I'd
| recommend YYYY/MM/DD as a less ambiguous format, but I don't
| have a perfect answer.
| jack_pp wrote:
| Pretty sure they force the user into that format so that
| shouldn't be an issue
| kriops wrote:
| Furthermore, require dashes over slashes to signal that you
| are expecting ISO-8601 compatible dates, i.e., YYYY-MM-DD.
| Most users does not know the standard even exists, but it
| serves as an affordance that it is _different_ from dd
| /mm/yyyy, etc.
| PaulHoule wrote:
| 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.
| titzer wrote:
| ISO 8601 is _the way_.
| cyanydeez wrote:
| alas, the user doesnt know the way...
| PaulHoule wrote:
| That part is easy. Use a date picker of some kind
|
| https://developer.mozilla.org/en-
| US/docs/Web/HTML/Reference/...
|
| or a text field with some code that converts vernacular
| dates to a structured format. I don't think users are
| going to be too weirded out at seeing "1997-04-15" and
| will probably learn to use that natively.
|
| The hard part is that a lot of devs aren't aware that
| there's a standard and that standard is superior to the
| alternatives.
| homebrewer wrote:
| You must mean RFC 3339.
|
| https://ijmacd.github.io/rfc3339-iso8601/
| bobmcnamara wrote:
| Out blasphemous temporal demon! Out!
| tshaddox wrote:
| Yes, except for all the completely unhinged stuff in ISO
| 8601. You probably do not want to deal with durations, or
| repeating intervals, or even week dates and ordinal
| dates.
| happytoexplain wrote:
| This isn't really relevant to the parent's topic though,
| aside from UX. The UI can tell the user which is the day and
| which is the month. The logic layer knows the format
| explicitly.
| senfiaj wrote:
| Every time I see an input date string in XX/XX/YYYY format I
| get a micro PTSD flashback. This cannot be parsed reliably
| and is locale dependent. The standard date format is YYYY-MM-
| DD (it's also the date part of the ISO time format). Raw text
| inputs should be avoided as much as possible, date/time
| pickers should be preferred.
| hanche wrote:
| Even worse with just two digits for the year! 01/02/03
| could be 1 Feb 2003, or 2 Jan 2003, or 3 Feb 2001. Let's
| just be thankful no one ever uses any of remaining three
| permutations.
| dragonwriter wrote:
| > The standard date format is YYYY-MM-DD (it's also the
| date part of the ISO time format)
|
| Strictly, it is the extended form of the ISO 8601 calendar
| date format. (The basic format has no separators.)
|
| ISO 8601 allows any of its date formats (calendar date,
| week date, or ordinal date) to be combined with a time
| representation for a combined date/time representation, it
| is inaccurate both to call any of the date formats part of
| the time format, and to call the calendar date format _the_
| format that is part of the combined date /time format.
|
| (There's a reason why people who want to refer to a simple
| and consistent standard tend to choose RFC-3339 over ISO
| 8601.)
| PaulHoule wrote:
| I guess in your case you're never doing date arithmetic or
| greater than or less than, but only doing equality testing,
| right? That is, it's part of a composite key.
|
| I faced a similar problem with a form where people were
| supposed to submit a date and probably not aware of what
| timezone was involved. I figured that so long as they selected
| "02/28/1993" and people always saw "02/28/1993" that was
| correct and if they ever saw it differently it was wrong. So I
| used non-TZ aware dates throughout the whole system.
| kaoD wrote:
| 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
| across the world for any timezone or calendar system. This is
| what we usually use "Unix UTC timestamps" for.
|
| - ZonedDateTime: like an Instant but associated with a
| particular calendar and location. Think an Instant but rendered
| "real" into a calendar system and timezone so the user can see
| a meaningful time for them.
|
| - PlainDate: already discussed. Think e.g. birthdates.
|
| - PlainTime: think "run task every day at 6:30pm".
|
| - PlainDateTime: like an Instant but associated with a calendar
| system, but no timezone. Think e.g. what a user would insert in
| a datetime picker, where the timezone is implied instead of
| explicitly selected.
|
| - PlainYearMonth: think e.g. "we'll run our reports during
| October 2025".
|
| - PlainMonthDay: think e.g. "my birthday is June 13".
|
| - Duration: think e.g. "the task ran for 3hrs 30min".
|
| Also see its important concepts[2].
|
| [0] https://tc39.es/proposal-temporal/docs/
|
| [1] https://tc39.es/proposal-temporal/docs/#Temporal-PlainDate
|
| [2] https://tc39.es/proposal-temporal/docs/timezone.html
| keeganpoppen wrote:
| 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.
| benreesman wrote:
| Relatedly, std::chrono isnt exactly a beauty, but it did
| get people thinking about time points and durations and
| clocks and which operations are valid ways to move among
| them. Stuff like this is good.
| Terr_ wrote:
| I hope that is time goes on software design get better about
| marking information as guesses or conjecture or probabilities
| rather than facts.
|
| As-is, we assume lots of things are facts and we just hope
| it's true enough to avoid problems. (Starting with the
| business requirements. :p )
| dragonwriter wrote:
| What environment are you in where you have to work with
| birthdates, you have timezone aware dates, times, and
| intervals, but you don't have a naive/plain/local date type
| that already exists forcing you to use strings in place of
| date-without-timezone?
|
| You seem to have a reasonably expedient solution for that
| problem, but it is surprising to have the combination of things
| you have to have and things you have to be missing to have that
| problem in the first place.
| BurningFrog wrote:
| Normal/"legal" dates are not timestamps or related to
| timezones, and this fact will eternally be rediscovered as long
| as humans write software.
| shadowgovt wrote:
| IIUC why medical cares at all, this is really insightful.
| Because as far as I'm aware, the medical industry basically
| uses birthdate _as_ a key; it helps to (a) tell two patients
| with other primary keys (like name or address) apart and (b) do
| a quick mental-acuity check on the patient by just having them
| regurgitate the value and doing a human-brain string= on it.
| legulere wrote:
| If you store it just as a string it means that you cannot do
| anything useful with it like age-dependent logic or you just
| pass on parsing logic to users of the field.
|
| FHIR in my opinion has a pretty good system for dates
| (including birthdates): YYYY, YYYY-MM, or YYYY-MM-DD. (Not
| knowing your exact birthday is common for some countries).
|
| https://build.fhir.org/datatypes.html#date
| danesparza wrote:
| I mean. Yes. Don't write your own date parsing library. Unless
| you want to go nuts.
|
| https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b...
| micromacrofoot wrote:
| 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?"
| indymike wrote:
| Add phone numbers, email addresses and human names to the list.
| econ wrote:
| Just validate the registration form? Surely this is a solved
| problem?
|
| Uhhh...
| micromacrofoot wrote:
| What do you mean we shouldn't have a first and last name
| input?
|
| _explains the naming conventions of every culture on the
| planet_
| peheje wrote:
| Agreed! My team is constantly humbled by the mess of user
| data: names, birthdays, addresses, people dying or living
| abroad etc.
|
| 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.
| davidw wrote:
| 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"
| TheJoeMan wrote:
| 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".
| Arainach wrote:
| People want to understand when things are open/reasonable
| without having to do a lookup every time. A conversion has to
| happen _somewhere_ - either I can say "X is in timezone foo.
| It's 1300 there so they're awake and I can call them" or
| "It's 1900 UTC, X is awake from....err....2200 to 1400, so I
| can call now".
|
| The first is significantly easier as it requires remembering
| only a single offset and then going with societal
| conventions.
| dmoy wrote:
| iirc DST was never about farmers, and always about energy
| usage (lighting, etc) in the evening
|
| Agree I've never met a farmer who cares about DST. Though
| also, for non-ag farmers, sometimes "crack of dawn" isn't
| early enough lol. Cow: "Dairy barn has electric lights, why
| aren't you awake at 4am tending to my needs, Human? Vacation?
| Lol no, stay here. Every morning. 4am."
| devilbunny wrote:
| Farmers who have to buy things (and that's almost all of
| them) care about the hours the shops are open, which is
| affected by DST.
| bluGill wrote:
| And farmers are annoyed that one day the shop is open just
| after dawn, and the next not for another hour. Farmers are
| building their life around sunrise/sunset (or sometimes the
| dew cycles which is tied to the sun), and then fit the rest
| of the world in between.
| johnnyanmac wrote:
| We're mostly still a diurnal species. We go to bed at 9PM
| instead of 9Am for evolutionary reasons. We can fight against
| it, but the reasons are as arbitrary as biology is.
|
| 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.
| jameshart wrote:
| Time zones are less about having uniform names for the times
| for waking up or going to work or mealtimes, and more about
| when your calendar changes from one date to the next.
| 3cats-in-a-coat wrote:
| Every time someone mentioned "days" or "months" or "years" in
| Andor I had to mentally zap my brain not to think about how it
| doesn't make a sense across a galaxy.
| jerf wrote:
| Consider it a translation convention. There's a time and a
| place for "cycles" or "rels" or whatever, but it gets into
| "Calling a Rabbit a 'Smeerp'" [1] territory pretty quickly.
| The payoff isn't really all that great.
|
| Stargate SG-1 is one of my favorite instances of this. The
| first couple of episodes address the fact that the Earth
| characters do not speak the same languages as everyone else
| in the galaxy. Then, having established the point that A: the
| show runners understand this is an issue and B: it makes for
| a rather tedious watch, they moved on to "everyone speaks
| English" and we all breathed a sigh of relief. I just think
| of it as part of the "camera" now. It turns out that we don't
| necessarily want a truly literal recording of what such
| things would look like.
|
| [1]: https://tvtropes.org/pmwiki/pmwiki.php/Main/CallARabbitA
| Smee...
| tetha wrote:
| I think that these fundamental things can be turned into an
| interesting topic, but you have to try for it.
|
| Like, in a story background I'm pushing around, there's a
| coalition of a large amount of species developed on
| different planets. And you're a military officer, and you
| need to coordinate shifts, but - assuming some collectively
| normalized number of hours - some of your tiny dudes are
| tuned to 3 hours of sleep, 3 hours of leisure and 3 hours
| of work, others weird dudes with 2 arms and 2 legs are
| tuned to 3 _8 hour cycles, and some huge dudes with a trunk
| in their face are tuned to 3_ 56 hour cycles.
|
| Even if you could train and adjust this by an hour or two
| (which, for the 3 hour dudes would compare to an 8 earth-
| hour extension of duty for us), how the heck would you
| coordinate any kind of shifts across this? Or does every
| species have their own schedule? Good look finding
| crossover meetings then. Some of the small guys would have
| to do overtime for longer meetings even.
|
| But you have to make it a point of the story and the
| challenges if you want to include it. If it is just a weird
| side note, just say that they figured out a conversion and
| that's it.
| ceejayoz wrote:
| > The payoff isn't really all that great.
|
| If you've read David Weber's Safehold series, this point
| gets super clear. It's written with names like "Zherald
| Ahdymsyn" (Gerald Adamson), but that makes it quite the
| slog for many.
| jgauth wrote:
| "The Hunt for Red October" had an interesting way of
| handling this with the Russian speakers. The movie starts
| with them speaking Russian with English subtitles, does a
| slow zoom into the Russian-speaker's lips, and switches to
| English mid-sentence.
| commandlinefan wrote:
| Like in Game of Thrones when Davos was trying to learn to
| read and incorrectly pronounced the word "knight" the way
| it was spelled - somehow I could accept that everybody in a
| fictional universe spoke English except for all the ones
| who spoke other fictional languages, but I drew the line at
| words being spelled the same as well.
| clem wrote:
| Vernor Vinge had it figured out in A Deepness in the Sky with
| the use of kiloseconds, megaseconds, and gigaseconds.
| BurningFrog wrote:
| 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.
| gleenn wrote:
| Case-in-point, you are mistaken. The duration of a day
| changes due to many things, both logically and also
| physically due to the nature of Earth. Also just because
| you can call a second a second doesn't mean that is
| helpful making datetime software usable or easy on a
| different planet.
| mikepurvis wrote:
| I think he's speaking historically. Obviously now a
| second is a fundamental SI unit defined in terms of
| physics experiments, but the _origin_ of it was as the
| amount of time that was 1 /3600th of an hour of which
| there are 24 in the day.
| shadowgovt wrote:
| Similar to how almost-pi-squared meters-per-second shows
| up in the constant for gravitational acceleration near
| Earth's surface because the meter was originally "the
| length of pendulum that ticks once a second" and there's
| a pi in the pendulum motion equation.
|
| (... it's not _exactly_ pi-squared because the French
| yanked it around a bit before settling into the modern
| number based on light in a vacuum and cesium atoms).
| layer8 wrote:
| The issue is that planetary locales will each have their
| own days and years (and possibly hours), so it would be
| confusing to adopt that same nomenclature for an
| interplanetary/interstellar time unit. And since the
| latter will be inconsistent with local time systems
| anyway, it's easier to just have it use powers of ten. At
| least until we meet aliens that may prefer a different
| base.
| ceejayoz wrote:
| Seconds are now (in SI) defined as calculated from
| behavior of cesium-133 atoms.
|
| https://en.wikipedia.org/wiki/Caesium_standard
| BurningFrog wrote:
| You can also define "days" and "years" in terms of that
| SI definition.
|
| I don't think that helps with the original concern.
| ceejayoz wrote:
| You can, yes. But having it all stem from some
| fundamental constant value any civilization can handle
| permits translation between civilizations.
|
| "Our dates start x trillion rotations of pulsar y ago and
| our unit is defined as z wiggles of cesium" is a starting
| point.
| bunderbunder wrote:
| 9,192,631,770 is clearly a sensible number and not
| something that's blatantly chosen to match some arbitrary
| pre-existing geocentric standard like 10,000,000,000
| would have been.
| ceejayoz wrote:
| It's retrofitted to what we already defined as a second,
| sure.
|
| But you can tell an alien species our units are expressed
| in multiples of that, and they can translate it into how
| theirs works. (Vinge, for example, has space-faring
| humans talk about "megaseconds" and "gigaseconds" rather
| than days/years.)
| benlivengood wrote:
| Unfortunately, the Second is measured for purposes of our
| timekeeping standards at sea-level on Earth which is
| ~1PPB slower than it would be in free space, as opposed
| to having a correction factor built into our time
| standards and so, for example, interplanetary ping times
| would be slightly shorter (in UTC/TIA nanoseconds) than
| expected.
| dizhn wrote:
| Babylon 5 times.
|
| https://babylon5.fandom.com/wiki/Measurements_of_Time
|
| Aliens use phrases like " 2 of your Earth days "
| Terr_ wrote:
| That makes me think of the foreword Isaac Asimov wrote for
| _Nightfall_ , explaining his choice of terms:
|
| > The essence of this story doesn't lie in the quantity of
| bizarre terms we might have invented; it lies, rather, in the
| reaction of a group of people somewhat like ourselves, living
| on a world that is somewhat like ours in all but one highly
| significant detail, as they react to a challenging situation
| that is completely different from anything the people of
| Earth have ever had to deal with. Under the circumstances, it
| seemed to us better to tell you that someone put on his
| hiking boots before setting out on a seven-mile walk than to
| clutter the book with quonglishes, vorks, and gleebishes.
| amelius wrote:
| Well, that problem exists now too, but everybody sticks their
| head in the sand.
| the__alchemist wrote:
| Good general rule of thumb, but desperate scenarios call for
| desperate measures. I would never do this in Python or Rust for
| example, but it's necessary in Javascript; `Date` and `Moment`,
| are so full of traps that the ends justify the means: Especially
| if you have use for a `Date` or `Time` type.
| jimmaswell wrote:
| moment's given me no trouble at all. I certainly haven't found
| it to be full of traps. Addressing the most common complaint: a
| moment object is mutable, sure - that's a valid design choice,
| not a trap. Follow the docs and everything works perfectly well
| IME.
| the__alchemist wrote:
| As a specific point, I have not safe found a way to represent
| a date or time in Moment. When I point this out, I generally
| get agreement from people who are more used to other
| languages, and the claim that "You should never be
| representing a date or time; everything should be a datetime"
| by JS devs.
| thangalin wrote:
| On a slightly related note, here's an algorithm for parsing time
| from natural inputs into a normalized time:
|
| https://stackoverflow.com/a/49185071/59087
| jimmaswell wrote:
| moment is far smaller if you include it without locales you don't
| need.
|
| I don't care how much they talk themselves down on their
| homepage, begging me to choose a different library - I like it
| and I'll continue using it.
|
| > We now generally consider Moment to be a legacy project in
| maintenance mode. It is not dead, but it is indeed done.
|
| > We will not be adding new features or capabilities.
|
| > We will not be changing Moment's API to be immutable.
|
| > We will not be addressing tree shaking or bundle size issues.
|
| > We will not be making any major changes (no version 3).
|
| > We may choose to not fix bugs or behavioral quirks, especially
| if they are long-standing known issues.
|
| I consider this a strength, not a weakness. I love a library
| that's "done" so I can just learn it once and not deal with
| frivolous breaking changes later. Extra bonus that they plan to
| continue making _appropriate_ maintenance:
|
| > We will address critical security concerns as they arise.
|
| > We will release data updates for Moment-Timezone following IANA
| time zone database releases.
| TheBigSalad wrote:
| I couldn't agree more. I have no idea why the moment devs are
| trying to kill moment.
| FigurativeVoid wrote:
| I used to work at a company that stored all dates as ints in a
| YYYYMMDD format. When I asked why, I was told it was so we could
| subtract 2 dates to get the difference.
|
| I asked them why they couldn't use DATEDIFF since this was in a
| sql db.
|
| They said they hadn't heard of it and that it must be new.
| dguest wrote:
| Wait so one day over the new year is
|
| 2025-01-01 - 2024-12-31 = 20250101 - 20241231 = 8870
|
| i.e. 90 months and 10 days
|
| or 7 years 6 months and 10 days
|
| How is that the same thing as one day?
| jabroni_salad wrote:
| In mainframes, Julian dates are popular for that reason. YYDDD
| (day of year).
|
| When is 30 days after today? 25206+30
| alexanderchr wrote:
| Maybe I'm missing something but then what is 30 days after
| Christmas? 25389?
| mpyne wrote:
| 25389 mod 365, presumably. The very fancy mainframes
| probably would pick the appropriate modulus based on
| whether it was a leap year or not.
| wood_spirit wrote:
| Yeah don't do it!
|
| But subtle plug of something I made long ago for when you find
| your data pipelines are running hot parsing timestamp strings
| etc: https://github.com/williame/TimeMillis
|
| I'm still pumped by the performance of the thing! :)
| bob1029 wrote:
| I like to use the Japanese calendar as an example to scare the
| juniors away from DIY parsing:
|
| https://learn.microsoft.com/en-us/dotnet/api/system.globaliz...
|
| https://learn.microsoft.com/en-us/windows/apps/design/global...
| colesantiago wrote:
| I don't see anything wrong with this. This is actually a fun
| challenge.
|
| I encourage everyone to learn how to parse the japanese
| calendar format.
|
| The more people know the better!
| kccqzy wrote:
| Do your users type in such dates? No? Problem solved.
|
| The benefit of DIY parsing is to make the problem simple by
| restricting it to the set of plausible inputs your users will
| want your code to handle, not to make a highly general library.
| The right takeaway for juniors is to stop over-complicating
| things.
| jedberg wrote:
| Things you should never do:
|
| Make your own load balancer software
|
| Make firewall software
|
| Make a date parsing library
|
| Attempt to verify an email with a regular expression.
| 9rx wrote:
| Roll your own encryption
|
| Accept people's names
|
| Anything
| the__alchemist wrote:
| Is parsing HTML with regexes Ok?
| dimaaan wrote:
| No. See https://stackoverflow.com/questions/1732348/regex-
| match-open...
| 9dev wrote:
| > Attempt to verify an email with a regular expression.
| .+@.+
|
| That one always seemed sufficient for me, every issue after
| that is the users problem
| jedberg wrote:
| Obviously there is a bit of nuance here, but the best rule of
| thumb is use a regex and then _warn the user that it doesn 't
| look valid_ but _still accept it_ if it doesn 't pass, and
| then send an email to verify it.
| fitsumbelay wrote:
| before I even read the post lemme just say "too late, friend.
| faaaaar too late ..."
| senfiaj wrote:
| In UIs prefer date/time pickers instead of raw text inputs which
| will give the date/time in standard ISO format such as
| ("2025-07-25" or "2025-07-25T18:47:26.022Z"). Prefer ISO formats
| everywhere where possible.
| somat wrote:
| The thing that bothers me about the firefox date picker is it
| display the date in YYYY/DD/MM format.
|
| While I am fairly sure this a a locale defined thing. locales
| are this huge pile of worms and I have never figured out how to
| change it to show YYYY-MM-DD format
| x187463 wrote:
| Relevant Computerphile: https://www.youtube.com/watch?v=-5wpm-
| gesOY
| CurtHagenlocher wrote:
| In 2009 I made a note that Excel's main date parsing function was
| over 1000 lines of code -- not including helpers.
| takinola wrote:
| 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 again.
| whatever1 wrote:
| It's because it is not systematic historically. It's a system
| full of edge cases
| hnuser123456 wrote:
| It's also a beautiful maze of nerd snipes. There's apparently
| some shifting going on inside the earth, combining with the
| slight variability of the moon's distance, which means
| various days over a month can be more than a millisecond
| shorter than average. Good luck integrating that into your
| date.addDays()
| cbm-vic-20 wrote:
| Unfortunately, not many people in our industry really
| understand the common pitfalls of timezone management,
| including the people who set the requirements. The classic "I
| want this to run at 2am each weekday for the user", and then
| proceed to simply store that as a UTC offset and call it a day
| (pun intended).
| shadowgovt wrote:
| The really important thing to remember about timezones is
| they're not a mathematical construct, or a physics construct,
| or an astronomy construct... They're a _political_ construct.
| Framed in that light, they have every bit the complexity of
| having some piece of your code depend on the law (except it 's
| the law of every nation you expect to be running your code in).
| joe_guy wrote:
| To that point: https://devblogs.microsoft.com/oldnewthing/200
| 30822-00/?p=42...
| servercobra wrote:
| I agree with everything other than "moment is great". Even the
| devs say don't use it any more, and accidentally mutated
| datetimes have been the source of bugs in apps I've worked on
| multiple times. Luxon is great though.
| alex_c wrote:
| Except you do still have to think about time, no matter what...
| Libraries will help with the really messy details, but even the
| high level requirements have a lot of pitfalls.
|
| "Simple" example that anyone who's ever worked on a scheduling
| application will probably be familiar with:
|
| "Get a list with all of today's events."
|
| Well, whose "today" (timezone) are we talking about? Server,
| client, setting in the user account? Or none of the above, and
| actually timezone at the physical location of the event, if
| there is one?
|
| And what does "today" mean, anyway? Truncate the date?
| 00:00-23:59? Business hours?
|
| And what does "today's event" even mean? Events can cross
| midnight... Does an event need to start today? End today? Both?
| Can events span multiple days?
|
| The fun never ends!
| ori_b wrote:
| Libraries can't paper over the hard parts of dealing with
| timezones. There are many "right answers" for most date
| problems. And, they're all what you want for some context. So,
| the library can't be opinionated about most things.
|
| You just need to understand how time works if you write code
| handling time.
| quelsolaar wrote:
| When ever i see "never implement your own...", i know i want to
| implement it myself. People say that about hard things, and I
| only want to do hard things. Nobody wants people who can do easy
| things, people want people who can do hard things. The only way
| to learn how to do hard things, is to do hard things, so do the
| hardest things.
|
| So go ahead, write your own date library, your own Unicode font
| rendering, compiler, OS, game engine or what ever else people
| tell you to never do because its hard.
| fsckboy wrote:
| you want to do something people really think is hard? use C.
| it's not safe.
|
| all the people who say C is not safe have downvoted me for
| quoting them
| quelsolaar wrote:
| I exclusively write in C89. I'm a member of the ISO C
| standard board.
| boothby wrote:
| The confluence of tinker-for-tinkerings'-sake "hackers" and
| get-rich-quick "hackers" on this site certainly leads to a
| lot of fun miscommunication.
| glibby wrote:
| By all means, write it. Just don't _use_ it. These warnings are
| almost always in the context of code you 're going to release,
| not exercises in learning on your own.
| ramijames wrote:
| This is such nonsense. All the stuff that we use, someone
| wrote. If nobody makes them, then how is that going to work?
|
| The messaging here is that you should be careful about using
| what you build on your own because it:
|
| - hasn't been battle tested
|
| - likely has bugs
|
| - isn't mature
|
| The only way that it will be all of those things is if
| someone invests time and energy in them.
|
| From an ecosystem perspective this is absolutely the right
| thing. You want duplicate projects. You want choice. You want
| critical knowledge to be spread around.
| Swizec wrote:
| > If nobody makes them, then how is that going to work?
|
| I see it as "Dont write your own X, _unless you want to
| maintain X_. Here be dragons, this problem is deeper than
| it appears, the first 80% will be easy, the next 15% will
| annoy you, and the last 5% will consume your life for
| weeks, months, or even years. Or you could use a library"
| DANmode wrote:
| Holy shit.
|
| The point is, before you release your new thing, _make sure
| it addresses all of the pain points the previous solutions
| have already slogged through_ ,
|
| or that if it _doesn 't_, people are still aware of when
| they can arise, and why your thing has chosen not to
| mitigate them yet,
|
| or ever, if it's an opinionated piece of tech.
| commandlinefan wrote:
| Nah, finding that stuff is what users are for.
| mattmanser wrote:
| It's about exposure.
|
| The things that people write that everyone uses have had
| HUGE exposure.
|
| They've been exposed to all the edge cases, they've been
| tested millions, if not billions of times. All the bugs
| ironed out.
|
| The people who've worked on them are now the greatest
| domain experts on that little corner of comp-sci.
|
| Yours won't unless it hits prime time.
|
| So yours will be weak, brittle and dangerous.
| gmueckl wrote:
| In order to have these mature libraries, someone hat to
| start building them. They all had to to be incomplete,
| immature and horribly buggy early in their lifetime, too.
| ozim wrote:
| I think there is missing point in this discussion.
|
| Most of the time you build something else.
|
| Like if you build a todo app and have to deal with
| scheduling you don't spend time making date library because
| it's not your goal. But people would do that.
|
| Heck most developers instead of starting blog on a blog
| platform start writing code for their own blogging engine.
| flir wrote:
| In the case of date libraries, I think if I ported the tests
| from a few well-known libraries to my own, I'd have
| reasonable confidence in my own.
|
| Having said that, I don't think date libraries are _hard_ , I
| think they're _messy_. Mostly because humans keep introducing
| convenience fudges - adding a second here, taking eleven days
| off there, that kind of thing.
| benlivengood wrote:
| I would not be surprised if the state of unit tests on good
| date parsing libraries are not sufficient to design a new
| one from scratch.
|
| See the number of unit tests in the Linux kernel, for
| example.
| flir wrote:
| You might be right, I haven't checked. It just seems on
| the face of it such an easy thing to test. Scalars go in,
| scalars come out. (This could just be me doing the
| Dunning-Kruger thing).
|
| You could run a fuzzer against two libraries at the same
| time to find discrepancies....... hmm. That might
| actually be a good exercise.
| leakycap wrote:
| I get wanting to do hard things, but do you write in binary? Do
| you crank your own electricity?
|
| My most valuable resource is time. Sure, I could learn more
| low-level aspects of my craft ... and sometimes I find it
| useful to do so.
|
| When I focus on doing the hardest, already solved things by re-
| implementing them my own way, what value am I adding?
|
| I've never met a client who cared about a library or how I did
| something in code - until it broke. Then, they didn't care who
| wrote it, they just cared it started working again.
| ok_dad wrote:
| People have built tables but I still build tables myself. Not
| as many people will use them as people who use IKEA tables,
| but that's okay, I'm still going to build them.
| bobsmooth wrote:
| Solve new hard things instead of solved hard things.
| qwertox wrote:
| This past 22nd of July was the shortest recorded day [0]. How
| would your library handle this?
|
| [0] https://www.space.com/astronomy/earth/earth-will-spin-
| faster...
| gmueckl wrote:
| Answer: not at all, unless I had to deal with astronomical
| time to compute locations of celestial bodies with high
| precision.
| VohuMana wrote:
| I think in the case of the article the date library isn't
| necessarily hard but tedious. They mention most date libraries
| suffer from supporting too many standards or allow ambiguity.
|
| I agree with you though, do the hard things even if it doesn't
| work 100% right you will have learned a lot. In university I
| had to implement all of the standard template library data
| structures and their features, it wasn't as robust as the
| actual STL but the knowledge of how those work under the covers
| still comes up in my day to day job.
| david-gpu wrote:
| Software companies make money by providing value to their
| customers via the software they provide. How does
| reimplementing a hard but already well-solved problem align
| with their goals? How does that compare with solving a hard
| problem for which there are no good solutions yet?
| avanwyk wrote:
| I can't believe this is such a controversial take. Solving hard
| things by yourself is growth. I 100% agree, rather solve a hard
| solved problem yourself than learning yet another JS framework
| or launching yet another revenue losing SaaS ("successful"
| because of VC). Or whatever. Push hard boundaries.
| brianpan wrote:
| It's controversial because 1) good on someone for wanting to
| do something difficult and 2) I cannot think of a worse thing
| to try to implement. Maybe trying to parse the world's postal
| and street addresses is a close second?
|
| Just, why.
| aaroninsf wrote:
| Funny,
|
| I wrote my own, so had to click, but mine was for a very
| different use case: converting extremely varied date _strings_
| into date ranges,
|
| where a significant % of cases are large number are human-entered
| human-readable date and date range specifiers, _as used in
| periodicals and other material dating back a century or two_.
|
| I.e. I had correctly interpret not just ISO dates, but, ambiguous
| dates and date ranges as accepted in (library catalog) MARC
| records, which allows uncertain dates such as "[19--]" and
| "19??", and, natural language descriptors such such as
| "Winter/Spring 1917" and "Third Quarter '43" and "Easter 2001."
| In as many languages as possible for the corpus being digitized.
|
| Output was a date range, where precision was converted into
| range. I'd like to someday enhance things to formalize the
| distinction between ambiguity and precision, but, that's a
| someday.
|
| When schema is totally uncontrolled, many cases are ambiguous
| without other context (e.g. XX-ZZ-YYYY could be month-day-year or
| day-month-year for a large overlap); and some require fun
| heuristics (looking up Easter in a given year... but did they
| mean orthodox or...) and arbitrary standards (when do seasons
| start? what if a publication is from the southern hemisphere?)
| and policies for illegal dates (Feburary 29 on non-leap-years
| being a surprisingly common value)...
|
| In a dull moment I should clean up the project (in Python) and
| package it for general use...
| neilv wrote:
| This article doesn't get into some of the special fun of ISO
| 8601, including relative values, non-Gregorian values,
| durations...
|
| Some of the things in the standard are surprising, like maybe
| were a special request. At the time, I commented, something like,
| _Somewhere, in the French countryside, there is a person who runs
| an old family vineyard, that is still stamping their barrels with
| the timepoint information [...]. And that person 's lover was on
| the ISO 8601 committee._
|
| (I once wrote an time library in Scheme that supported everything
| in ISO 8601. It did parsing, representation, printing, calendar
| conversion, and arithmetic. Including arithmetic for mixed
| precision and for relative values. It was an exercise in really
| solving the problem the first time, for a core library, rather
| than cascading kludges and API breakage later. I don't recall
| offhand whether I tried to implement arithmetic between different
| calendar systems, without converting them to the same system.)
| endoblast wrote:
| I'm not even a programmer, but I can tell that dates are
| ambiguous a lot of the time.
|
| e.g. dd/mm/yyyy (British) and mm/dd/yyyy (USA) can be confused
| for the first twelve days of every month.
|
| So, given the high volume of international communication, I think
| we should hand-write months in full, or at least as the first
| three letters (Jan, Feb, Mar, ..., Dec)
|
| We should also abandon three-letter acronyms (but that's another
| story).
| macintux wrote:
| I wrote one in Erlang years ago for Riak's time series
| implementation. I don't remember all of the motivations, but most
| of all I wanted the ability to encode incomplete date/time
| objects.
|
| https://github.com/macintux/jam
|
| I'd like to get back to it. If nothing else, I dearly miss using
| Erlang.
| champtar wrote:
| I once had to maintain a CalDAV server that was developed in
| house, computing the "free busy" with recurring events,
| exceptions, different timezone than the organizer + some DST is a
| bug source that keeps on giving.
| fHr wrote:
| fucking daylight saving time I had to fix a few weeks ago on the
| change back on last Sunday October where the same hour occurs
| twice _._
| Hizonner wrote:
| Never mess with cryptography, times, Unicode, or floating point.
___________________________________________________________________
(page generated 2025-07-25 23:00 UTC)