[HN Gopher] Never write your own date parsing library
___________________________________________________________________
Never write your own date parsing library
Author : ulrischa
Score : 245 points
Date : 2025-07-25 17:36 UTC (1 days 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...
| oneshtein wrote:
| Why not just make a map of dates to days since 0001-01-01
| in a plain text, then compress it at build time? We are
| not constrained by memory anymore.
|
| Just use simple database as source of truth with all days
| passed since a start of human history (e.g. 6000 years
| ago) with labels such as "this day 12345678 was known as
| day XXXX-xx-xx in those regions, also known as YYYY-yy-yy
| in those regions, also known as ZZZZZ in this specific
| region". It's not a hard task to automatically compress
| such database into a compact representation.
| 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.
| oneshtein wrote:
| $ LANG=C date --date="01/02/03" Thu Jan 2 00:00:00
| EET 2003 $ LANG=de_AT.utf8 date
| --date="01/02/03" Do 02 Jan 2003 00:00:00 EET
| $ LANG=zh_HK.utf8 date --date="01/02/03" 2003Nian
| 01Yue 02Ri Xing Qi Si 00:00:00 EET
| 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 as time goes on software design get better about
| modeling things that are guesses, conjecture, etc. rather
| than Absolute 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 )
| geocar wrote:
| > 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).
|
| It might also be relevant: Ever ask an older Korean person
| their age?
|
| > 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.
|
| This is not a thing. Those are intervals to some Epoch, maybe
| taking into account leap-seconds and maybe not. They are not
| very useful except grossly over long ranges.
|
| > - 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.
|
| Like when a user logged in at X date and time. They don't do
| this from no location, but from some location.
|
| > - PlainDate: already discussed. Think e.g. birthdates.
|
| And already wrong.
|
| > - PlainTime: think "run task every day at 6:30pm".
|
| Erm no. You can say 18:30 hours after midnight, or you can
| say when the calendar says 6:30pm, but these are different
| things. Imagine the poor fool who wants to run the task every
| day at "1:30am" and has it run twice on some days.
|
| Bars close in some parts of the world at 30h (30Shi ) to mean
| 6am the following day.
|
| > - 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.
|
| No, like a string.
|
| > - PlainYearMonth: think e.g. "we'll run our reports during
| October 2025".
|
| Nonsense. Also a string.
|
| > - PlainMonthDay: think e.g. "my birthday is June 13".
|
| Your birthday might be on the 29th of January. You cannot do
| reasonable arithmetic with such things, so it might as well
| be a string like many of these others.
|
| > I like how Temporal[0] does this.
|
| I don't if you can't tell. This stuff is complicated and I'd
| like more people exploring it because I don't know The Right
| Answer(tm) either, but I know enough to know that every
| existing solution is wrong in some way that can cause real
| harm.
| kaoD wrote:
| Just FYI you were downvoted with no explanation because you
| missed the point in all of these and you're using a smug
| and off-putting tone which makes it look like only care
| about "being right" and not finding what "is right".
|
| Also you obviously didn't bother reading the "important
| concepts" link ([3]).
|
| I was going to assume good faith and reply to each of your
| comments but it'd probably be a waste of time. As a
| summary: most of your concerns are wrong due to (1)
| confusing "timezones" with "location" or
| "internationalization" (2) confusing internal
| representations (like Epochs) with what these objects
| represent as described in the "important concepts" link and
| (3) just being completely wrong like saying you cannot do
| reasonable arithmetic with PlainMonthDay or even understand
| that not every relevant operation is arithmetic (good luck
| calling `.toPlainDate(2025)` with your string
| representation).
| 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.
| happytoexplain wrote:
| They may have something that's just not as easy to work with
| as strings. E.g. in Swift, you have DateComponents, but
| that's too dynamic (and Date is sometimes referred to as
| naive, but that's a misunderstanding, since they are
| timestamps, not date+time).
| 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_
| bigstrat2003 wrote:
| Which is _not relevant_ unless you are trying to support
| every culture on the planet. Which most people aren 't, and
| for them it'll be just fine to have first+last name.
| micromacrofoot wrote:
| You'd be surprised how often two fields mess up names if
| you live in a place that has any amount of immigration.
| 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.
| msla wrote:
| > "It's 1900 UTC, X is awake from....err....2200 to 1400,
| so I can call now"
|
| Assuming it's that simple of course. Like, you can do
| mental math about what UTC "officially means" for someone
| many miles away, but people coordinate with others even if
| it means their local schedule is not aligned with that
| ideal case. Time zones account for this by being wider or
| narrower than their Platonic 15deg of longitude ideal in
| some places.
| 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."
| slyall wrote:
| DST is not about energy use. If it actually saves energy is
| debated and depends a lot on the local climate and air
| conditioning usage etc.
|
| What it is about is moving an extra hour of daylight from
| say 5:30am-6:30am (when it is only of use to farmers and a
| few other early risers) to say 7pm-8pm when 95% of the
| population is still awake.
| 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.
| skrebbel wrote:
| I could not get through Banks' "Feersum Endjinn" for this
| sole reason. English isn't my first language, though I'm
| fluent in it and read lots of hard sci-fi in it. But half
| a book using English "spelling rules" applied haphazardly
| just to make a minor point about one character was well
| beyond my capacity. I quoted "spelling rules" on purpose
| because let's be honest, English doesn't really have any.
|
| You couldn't translate that novel to Italian or Finnish,
| or any language with proper phonetical spelling.
| UltraSane wrote:
| As a native speaker I found it pretty easy to read.
| 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.
| jkingsman wrote:
| With some elegance, too; iirc they pivot languages on the
| word "Golgotha" as he reads from the bible, the Latin
| word for a location near Jerusalem, but having a non-
| English/non-Russian word be when they switch made it a
| lot less jarring. Plus, having it be during a read-out-
| loud-from-book portion allowed for more measured cadence
| that smoothed the switch but probably would have felt
| jarring if the audience were parsing multi-character
| dialogue when it happened.
| nwallin wrote:
| > they pivot languages on the word "Golgotha"
|
| "Armageddon" actually. Poignant because it's a movie
| about a nuclear ballistic submarine. But not a
| particularly non-English word.
| stevage wrote:
| I found that incredibly clunky when I saw it. Also, it's
| a little bit extra jarring that Sean Connery goes from
| speaking Russian to speaking English with a Scottish
| accent.
| sms95 wrote:
| That trick has been used in movies before that too.
| "Judgment at Nuremberg" does something similar. A
| character is speaking German, slow zoom, then a switch to
| English.
| 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.
| BurningFrog wrote:
| I was 100% thinking of use by humans living on other
| worlds. Pretty sure Mars will use seconds and hours.
| Handling dates will awkward whatever they decide on.
|
| Currently, a Mars days is called "sol", FWIW.
|
| If we find other species out there I won't speculate on
| how they think about time.
| GoblinSlayer wrote:
| But this makes no sense, humans can't just change their
| circadian rhythm to match an arbitrary daylight cycle,
| and clocks aren't necessarily reconfigurable. And with a
| good enough artificial lighting you don't need to depend
| on star. Daylight is just weather, it has nothing to do
| with how calendar works.
| 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.)
| db48x wrote:
| > "megaseconds" and "gigaseconds" rather than days/years.
|
| More like weeks and decades. Arranging to meet someone in
| a megasecond is like meeting them on the weekend; a
| megasecond is ~11.5 Earth days. A kilosecond is short
| enough to be used for moment-to-moment planning. They're
| about a quarter of an hour each so they're good for
| scheduling work tasks, scheduling time to meet people for
| a meal, etc etc.
|
| Gigaseconds are more rarely used, since each one is ~32
| Earth years.
|
| Diaspora by Greg Egan has some fun with this too. The
| main character is a software emulation; called a citizen
| rather than a flesher. Most emulations live at a
| subjective rate 800x faster than the flesher normal. The
| second chapter is three flesher days after the first but
| 256 megatau, or ~8 years, have passed for the main
| characters. The fourth chapter is two thirds of a teratau
| later, over 20k subjective years. For the fleshers of
| Earth a mere 21 years have passed. The main character has
| actually forgotten the events of the third chapter; one
| of his friends brings it up and he has to search his
| archived memories to figure out what his friend is
| talking about.
| 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.
| oneshtein wrote:
| A much more precious clock is used by USA to guide
| nuclear missiles without GPS. (nucleus of Thorium 229
| controlled by a high-precision UV laser?)
| UltraSane wrote:
| That clock hasn't actually been built yet and it wouldn't
| be useful for guiding nuclear missiles.
|
| https://en.wikipedia.org/wiki/Nuclear_clock
| oneshtein wrote:
| I mean, than nucleus is much heavier and much smaller
| than electron, so it will be much less affected by
| external forces. We may see no difference between sea
| level and space based Thorium-229 clocks, or difference
| will be much smaller.
| greggyb wrote:
| Coming from an educational background of imperial units, I
| sometimes catch flak from ... most of the world about this.
|
| I take joy in exuberantly pushing back on their insistence
| of clinging to such archaic time units as "minutes",
| "hours", and "days", telling them to come back when they
| embrace kiloseconds. It is telling that most of my friends
| accept this with equal joy and laughter (:
|
| It probably doesn't hurt that I've also spent time drilling
| metric conversions so that I can code-switch pretty
| seamlessly among units. Neurotic tendencies can have
| payoffs.
| 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.
| mystifyingpoi wrote:
| Well, in entirety of SW (or at least in mainline movies) it
| is kinda strange, that day and night happens basically on the
| same 24h period as on our Earth, given that all the planets
| are different. Could make a much more interesting story
| without this crutch for the audience.
| scbrg wrote:
| https://starwars.fandom.com/wiki/Galactic_Standard_Calendar#.
| ..
|
| _The Galactic Standard Calendar or Galactic Standard Time
| was the standard measurement of time in the galaxy. It was
| based on the Coruscant solar cycle. The Coruscant solar cycle
| was 368 days long with a day consisting of 24 standard hours.
|
| 60 standard minutes = 1 standard hour
|
| 24 standard hours = 1 standard day
|
| 5 standard days = 1 standard week
|
| 7 standard weeks = 1 standard month
|
| 10 standard months + 3 festival weeks + 3 holidays = 368
| standard days = 1 standard year_
| 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?
| cortesoft wrote:
| It is even worse than that, each month boundary breaks it,
| too:
|
| 2025-02-01 - 2025-01-31 = 20250201 - 20250131 = 70
| rootsu wrote:
| They might be subtracting taking first 4 digits and the
| subtracing yyyy-yyyy, mm-mm and dd-dd.
| dguest wrote:
| Which sort of works, but then you also have to deal with
| the cases where the days or months go negative (at the
| month and year bounds), and that also involves knowing how
| many days there are in each month. It's pretty difficult
| for me to imagine how this could be easier than just
| converting to e.g. unix time and subtracting seconds.
| 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.
| cortesoft wrote:
| What happens when you want to add more than 365 days to a
| date, then?
| 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.
| bigstrat2003 wrote:
| > Do your users type in such dates? No? Problem solved.
|
| This is spot on. So many of the "X is really hard and your
| intuition is wrong" takes ignore the fact that most people
| are _not_ building something which needs to be usable in
| every country, language, and culture on this earth. Yes,
| human behavior is insanely complex, but for any given
| application you can probably ignore huge swathes of it.
| its-summertime wrote:
| I put these into an ISO8601 parser and it didn't work, I'm
| going to tell ISO off for obviously DIYing their solution
| instead of doing the proper thing.
| 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
| senfiaj wrote:
| At least the real input value is in YYYY-MM-DD. Also the date
| picker will show the day in it's calendar UI.
| 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!
| Clamchop wrote:
| I understand the complexity of time, but this scenario
| doesn't seem all that difficult. Any user expects (I won't
| get into what they want) to be shown _their_ day, and they
| expect it to be local calendar time. You _might_ want to show
| wee hours events, from midnight to just short of 5am. Apps
| like Teams do a good job of spacially illustrating time as it
| matters to you _and_ as it matters to others.
| 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.
| mavamaarten wrote:
| Especially because 99,9999% of the time I don't even care about
| any of the special cases, and I just want to show a simple date
| to a user.
|
| And still, you regularly run into issues, because our API or a
| third party did something silly
| fleebee wrote:
| moment.js has been deprecated for, what, close to 5 years now?
| I wouldn't recommend choosing it over any of the modern
| alternatives.
| 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.
| immibis wrote:
| Yeah, so do you want to go through that process of
| shipping broken crap and fixing user complaints one at a
| time until it happens to work for everyone, _which is a
| mandatory process for all new libraries in one of these
| areas to go through_ , or would you rather stand on the
| shoulders of someone who's already done it?
| kulahan wrote:
| Why would I mature yours and deal with those issues when
| I can just use the already-mature one?
| gmueckl wrote:
| You assume that you always have a mature option
| available. That's (a) definitely not a totally
| generalizable assumption and (b) my point is that mature
| options only exist because the people that developed them
| just did it when confronted with the task.
| kulahan wrote:
| We are specifically talking about something that does
| have a mature option available. That's why it's stupid to
| try and implement your own version of something complex.
|
| If you change the story such that the product is actually
| needed and universally immature, of _course_ building it
| is a valid argument.
|
| Regarding b: Right, and the point of this article is that
| for those types of things, go with what exists. You're
| arguing a point nobody is making.
| zelphirkalt wrote:
| This assumes, that the practices/methods used to create a
| working library are suitable for solving the problems.
| They might be ill-advised and include tons of workarounds
| for bad design decisions. Too often following the advice
| of never reinventing anything (and possibly doing
| better), is how we ended up with stacking broken stuff on
| top of other broken stuff, limiting us at every turn with
| leaking abstractions and bad designs.
|
| It is very possible to have a clean implementation with
| good design choices overtake an established in time,
| enabling more extensibility, modularity and
| maintainability.
|
| An example: People still way over-use regexes for all
| kinds of stuff. Even in code editors people for syntax
| recognition, where people really should know better.
| 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.
| mikestaas wrote:
| see https://rakhim.org/honestly-undefined/19/
| 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.
| shakna wrote:
| Most well-known date library systems have failed in places.
| Quite a few, still do. So whilst you might get some known
| regression to test against, nothing can give you a
| foolproof guide.
|
| You can have reasonable confidence that here there be
| dragons, but not so much that your assumptions about
| something will hold.
| tbrownaw wrote:
| > _Having said that, I don 't think date libraries are
| hard, I think they're messy._
|
| Messy is just a particular kind of tedious which is the
| most common form of hard.
|
| It's not like typical things that need doing tend to
| include solving lots of unsolved problems.
| bdangubic wrote:
| I write my own, but in production I always use libraries
| written by some dude from Omaha :)
| dylan604 wrote:
| And that dude is no longer actively maintaining it and you
| just discovered an issue with it.
| bigstrat2003 wrote:
| I think that advice makes sense in the context of
| cryptography, where the consequences for getting it wrong can
| be quite serious indeed. I don't think it holds true for
| something as unimportant as a date parsing library.
| poink wrote:
| Correct date handling (including parsing) can be
| monumentally important. Imagine an app that reminds people
| when to take their medications, for example
| what wrote:
| You typically take medication at a set time every day.
| You don't need to parse dates for that.
| poink wrote:
| 1) Dates are often stored as strings, so parsing them
| correctly is a necessary component of storing them. Also,
| those dates need not be simple app state. They could come
| from an API provided by your doctor/pharmacy
|
| 2) Many people (especially the elderly) take enough
| medications on different schedules that managing them all
| would be a significant cognitive load for anyone
|
| It's just an illustrative example, though. My point is
| getting dates right (including parsing their string
| representations) often matters quite a bit. If you
| disagree, let's argue about that rather than quibble
| about the minutiae of the example
| leptons wrote:
| A lot of cryptography relies on dates, time, etc.
| kuon wrote:
| Hard disagree here. Use it. Of course, if you running code
| that drive a pacemaker or a train maybe be careful, but in
| general, do things. We don't want a world where only three
| old bearded guys can write a compiler or a physic engine. Do
| the same errors again and you'll learn, eventually you'll do
| better than those who were here before you.
| Hnrobert42 wrote:
| >Maybe be careful
|
| Really?
| patrick0d wrote:
| Well don't do it and instead of using an off the shelf
| library that is known to work while the rest of the
| development team isn't reinventing the wheel. Doing it for
| fun and education is fine of course.
| sabas123 wrote:
| > We don't want a world where only three old bearded guys
| can write a compiler or a physic engine.
|
| Don't write your own OS does not mean do not contribute to
| something like the linux kernel.
| Zambyte wrote:
| It's interesting that people are disagreeing with you in a
| way that they're making it sound like they're elaborating
| on your point.
|
| To the people reading this, please don't just disagree with
| an "obvious counterexample". Explain why!
| breatheoften wrote:
| What IS the right way to model dates in a pacemaker ...? I
| hope the answer is "just don't do it" -- but I don't know
| what reasons there might be for a pacemaker to need to
| depend on calendar dates in order to best do its job ...
| fc417fc802 wrote:
| Well naturally it will need to connect to your phone via
| Bluetooth for the app to proxy update downloads and
| historic location data uploads. But in order to do
| anything on the network securely you need an accurate
| clock and the ability to parse datetimes because the PKI
| implementation depends on that.
|
| Then the app pings you to remind you that your premium
| subscription will be expiring soon after which your heart
| rate will be limited to 100 bpm or less.
| cmdlyne2 wrote:
| > By all means, write it. Just don't use it.
|
| I'd say write it, probably don't use it, and don't share it
| unless it's substantially better than the alternative.
|
| This way, you'll learn about it, but you'll more likely stay
| with something standard that everyone else is using, and you
| don't share yet another library that wastes others' time and
| your own (having to read about it, evaluate it, use it, and
| the migrate off of it when it's abandoned).
| 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.
| leakycap wrote:
| I don't think tables are the hard thing.
|
| If you wanted to grow your wood, plane and dry it yourself,
| etc... then you'd be "hard way" building a table.
|
| I assume you use tools?
| ok_dad wrote:
| I mean, a table is as hard as you make it. I work with
| rough construction lumber, and make nice finished goods,
| my point was that people still do stuff that isn't worth
| their time financially.
| leakycap wrote:
| > I mean, a table is as hard as you make it.
|
| We aren't talking about the same thing: I stated "I don't
| think tables are the hard thing."
|
| Note the word "the" in front of "hard thing" -- I'm
| referencing the article we're discussing, which mentions
| "the hard thing"
| cortesoft wrote:
| > I've never met a client
|
| There is difference between "never build your own for a
| professional need" and "never build your own".
|
| I build my own stuff if it is for my own purposes, and I use
| proper tools and libraries for my professional work.
| quelsolaar wrote:
| Writing in binary or cranking your own electricity is easy.
| Anyone can do it.
|
| There is a difference between things that are difficult and
| things that just take a lot of work.
| bobsmooth wrote:
| Solve new hard things instead of solved hard things.
| dafelst wrote:
| Or you know, just do what you want
| GoblinSlayer wrote:
| Most solutions are garbage though, because they evolved
| accidentally.
| 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.
| cortesoft wrote:
| No libraries handle this, though
| 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.
| stouset wrote:
| Nobody is really saying not to build these things. They're
| saying the problem is exceedingly annoying to solve--and
| often not in a technically interesting way but in a way that
| is just massively tedious--and a better alternative almost
| certainly already exists.
|
| If you want to build it to scratch an itch, go ahead. If you
| want to build it for fun, go ahead. If you want to build it
| because an existing solution gets something wrong and you can
| do better, go ahead (but know that it is a way bigger
| undertaking than you might assume at first glance).
|
| The real advice is "don't _casually_ build your own X", but
| that's less punchy.
| immibis wrote:
| An exemplary one is "don't build your own timezone
| database"
|
| It's not interesting, it's not fun, it's just a process of
| getting complaints it's wrong in edge cases and then fixing
| them, over and over until no one can find another broken
| edge case.
|
| You can start by writing down England is +0, Germany is +2,
| etc... someone's going to mention DST and you'll put in a
| field for switching on the Nth Sunday of month X... later
| you'll run into a country that uses a different rule and
| you'll add a bunch of spaghetti code or write a Turing-
| complete DSL, etc... One day someone tells you about a
| village where they count 17 hour days on seashells and then
| you'll give up.
|
| And if your DB doesn't produce identical results to the
| Olson DB in all cases then you created an incompatibility
| anyway. Might as well just use the Olson DB.
| thfuran wrote:
| >If you want to build it because an existing solution gets
| something wrong and you can do better, go ahead
|
| But please at least file the bug first.
| myaccountonhn wrote:
| I think it's a spectrum and most fall somewhere on the line,
| hopefully dependent on the project.
|
| My personal limit is rolling my own crypto, but I'm
| definitely more on the DIY scale because I agree. It's a
| fantastic way to grow and learn, and it's likely you might
| not have the energy to do it outside of work.
| dracodoc wrote:
| It's not because it's "hard".
|
| It's all about the nuisance created by human behavior.
| Calendar, DST, timezone, all the problems you never imagined
| can happen and can only be met in real life scenarios, and you
| will meet same problem again, struggle then found out the same
| problem have been solved long time ago by mature library, and
| the solution doesn't require any smart or advanced technique,
| just another corner case.
| geocar wrote:
| I disagree hard.
|
| Firstly because I have a great imagination, but secondly
| because I am old and have a lot of real life scenarios to
| think about.
|
| State-of-the-art here has changed a _few times_ in my
| professional career: Once upon a time most time /date
| libraries used a single integral type and try to make it do
| double-duty by being both interval and absolute (whatever
| that means) time by taking the interval from an epoch.
|
| _Relatively recently_ however, that 's started to change,
| and that change has been made possible by people using
| languages with better type systems reinventing the date/time
| approach. This has led to fewer bugs, and more predictability
| with regards to calendar operations in different programs.
|
| But bugs still happen, so this approach is still
| unsatisfying. One thing I keep having to worry about is
| distance; I record RTT as part of my events, since when I am
| looking for contemporaneous events, the speed-of-light
| actually tends to be a real factor for me.
|
| So I don't think this is solved simply because _my_ problems
| aren 't solved by existing libraries, and I keep getting into
| arguments with people who think GMT=TAI or something dumb
| like that.
|
| It's not "all about" anything: Nobody knows shit about what's
| happening in the next room over, and if there are 12
| different date/time libraries now, I guarantee there'll be a
| 13th that solves problems in all of them, and is still
| incomplete.
| rkagerer wrote:
| Don't forget to roll your own crypto libraries.
| djfivyvusn wrote:
| Yea, date time parsing is probably fine so is rolling your own
| auth, unicode, font rendering, compilers.
|
| Datetime libs themselves? No thanks.
| richardw wrote:
| Never write your own multi-planetary date/time library in
| brainfuck.
| whoamii wrote:
| ... but if you plan to sell it, don't build your own billing
| system!
| geocar wrote:
| Yes. Do it.
|
| The only way you understand X is by making your own X and
| trying to support it for a few decades, and our industry needs
| more people who understand X; fewer who just ask
| chatgpt/stackoverflow/google for "the answer".
| ozim wrote:
| Missing context is - there is always something else you work on
| like the guy was making Eleventy so it was waste of his time.
|
| If you work for a company and build todo app most likely it
| will not be beneficial for you to implement in-house library
| because there will be stuff that will bring much more value.
|
| Like you don't have now 2 years to cover for all hard stuff
| because you have to make synchronization of tasks between
| devices and your boss most likely won't appreciate that.
|
| "Never roll your own cryptography" is always used in context of
| building another application it is never "don't become a
| cryptography specialist".
| chii wrote:
| > The only way to learn how to do hard things, is to do hard
| things, so do the hardest things.
|
| and i don't want to pay my employees to learn, i want to pay
| them to produce output i can sell.
|
| Doing hard things are good, if this hard thing has never been
| done before - like going to the moon.
|
| Doing hard things which has been done, but just not by you, is
| not good unless it's for "entertainment" and personal
| development purposes - which is fine and i encourage people to
| do it, on their own dime. Like climbing Mount Everest, or going
| to the south pole.
|
| But if you are doing a project for someone else, you don't get
| to piggy back your personal wants and desires unrelated to the
| project on to it.
| schindlabua wrote:
| Except making employers do only easy things will make them
| stagnate. People who do nothing but simple CRUD apps over and
| over won't even be particularly good at making CRUD apps...
| whereas the guy who builds an Unicode font renderer in his
| free time always seems to write better code for some reason.
|
| Getting better at your job is not just a "personal want" but
| very much something that the employer appreciates aswell.
|
| Of course reinventing the wheel isn't good in corporate
| because the reinvented wheel is buggier than the ready made
| npm package but employers _should_ go out of their way to
| find hard problems to solve that they can pass to their
| employees. It 's called a growth opportunity.
| pjmlp wrote:
| Unless you work for enterprise consulting where employers
| appreciate replaceable cogs that they randomly drop into
| any project, and nicely out project budget regardless of
| delivery quality.
| keybored wrote:
| You can't convince an employer with that attitude. They're
| gonna keep exploiting their employees and "encourage" them
| to do their "personal development" in their free time.
| ahf8Aithaex7Nai wrote:
| > and i don't want to pay my employees to learn, i want to
| pay them to produce output i can sell.
|
| This can be a bad local optimum. It probably depends on what
| exactly your business does, but it can make sense to pay an
| employee to acquire knowledge and skills that are needed in
| the business. You can't buy this off the shelf in all
| circumstances. Of course, it also has to make economic sense
| and be viable for the company. Unfortunately, I often see
| employees doing things quite badly that they don't really
| understand because they are not given the opportunity to
| learn properly. I can't imagine that this burns less money in
| the medium and long term than giving paid employees adequate
| space to learn.
| pletnes wrote:
| Also as an employee, this forces me to job hop to stay
| relevant.
| pjmlp wrote:
| Unless you happen to live in cultures where that is
| looked down upon as not able to keep a job.
| pletnes wrote:
| Meaning you will job hop less, but you still have to
| weigh the advantage/disadvantage as always.
| quelsolaar wrote:
| Your customers will pay more for things that are hard to do.
| Ask ASML.
| motorest wrote:
| > Your customers will pay more for things that are hard to
| do. Ask ASML.
|
| What a silly example. ASML is valuable because it does
| something no one else does. It's not because it's hard,
| it's because they have the know-how and infrastructure to
| do it whereas others don't.
|
| Juggling is hard. Do you know any millionaire jugglers?
| bdhcuidbebe wrote:
| > Juggling is hard.
|
| You should try instead.
|
| I brought jugglers balls for my team and in a few weeks
| we had 4 or 5 fluent.
| seb1204 wrote:
| No one else does it, because it is hard I thought? Hard
| to get all the steps and processes aligned to produce
| what they do. It is so hard, that there is no rich guy
| that wants to throw money in the hat and do it himself.
| d_tr wrote:
| I am in a work environment where I actually get to do hard
| shit for fun, learn a ton, and also "get stuff done" and my
| employer is happy.
|
| For some of the stuff that has been done already, it might
| still make sense to do your own implementation, for example
| if you want to be able to experiment without having to
| navigate and learn a huge codebase and then have to maintain
| a fork just to have your own stuff in.
|
| Another project we are starting now involves replacing
| software which is outright crappy and wastes our time.
| Thankfully my employer was able to see and understand this
| after talking it through with them.
| bdhcuidbebe wrote:
| > i don't want to pay my employees to learn
|
| Then how do you expect them to learn?
|
| Good luck getting more blood out of that stone, smh.
| Latty wrote:
| Let's be a little charitable and assume they mean _just_
| learn. There are hard tasks you can learn from that also
| provide something you can 't just get off the shelf, rather
| than just reimplementing the wheel.
| rambambram wrote:
| Is quelsolaar your employee?
| psychoslave wrote:
| There are different kind of hardship though.
|
| There things which was a result will make your mind click to an
| other way to comprehend a problem space and how to navigate
| through it.
|
| And there are things which are hard due to pure accumulation of
| concurrent conventions, because of reasons like coordinating
| the whole humanity toward harmony with full happy peaceful
| agreement of everyone is tricky.
|
| Handling date is rather the latter. If you dig in the lucky
| direction, you might also fall into cosmological consideration
| which is a rabbit hole of its own, but basically that's it:
| calendars are a mess.
| motorest wrote:
| > People say that about hard things, and I only want to do hard
| things.
|
| That's perfectly fine. Your time, your hobbies.
|
| > Nobody wants people who can do easy things, people want
| people who can do hard things.
|
| No, not really. People want people who do easy things, because
| they are clever enough to avoid needlessly wasting their time
| having to do hard things when they could have easily avoided
| it.
|
| It's your blend of foolish mindset that brought us so many
| accidental complexity and overdue projects. There's a saying:
| working smart instead of working hard.
|
| > 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.
|
| You can cut it out, this isn't LinkedIn.
| d_tr wrote:
| In a scenario where a programmer has to do this for work and
| might naively think that date handling is simple, the title is
| invaluable advice. It is one of those things that can cause
| real trouble.
|
| OTOH writing, e.g., your own renderer could cause some funny
| display at worst and maybe some unnecessary effort.
| cookiengineer wrote:
| I feel obligated to comment on this.
|
| Due to my work I rely on web scraped data for cybersecurity
| incidents. For Amazon Linux, they are disclosed with the fvcked
| up US datetime format (Pacific Time) and not in ISO8601
| formatted strings which could imply Juliet/Local time.
|
| In 2007 there was a new law that changed when Pacific Time
| enters/leaves Daylight Saving Time. Instead of making this
| fixed by a specific Day of a specific Month in numbered form
| like say "YYYY-03-01 to YYYY-10-01", they literally wrote the
| law quoting "first Sunday of April" to "last Sunday in
| October". Before 2007 it was "Second Sunday in March" to "first
| Sunday in November".
|
| I'm not making this shit up, go ahead and read the law, come
| back and realize it's even more complex for other timezones,
| because some nations seem to make fun of this by going to
| +14:00 hours and -11:30 hours depending on the president's mood
| on Christmas or something.
|
| In order to find out the Day of a specific calendar date,
| there's this cool article about Determination of the day of the
| week [1] which is quite insane on its own already. There is no
| failsafe algorithm to do that, each method of determining the
| day of the week has its own tradeoffs (and computational
| complexity that is implied).
|
| Then you need to get all Sundays of a month, count the right
| one depending on the year, map back the date to ISO8601 and
| then you know whether or not this was daylight saving time
| they're talking about. Also make sure you use the correct local
| time to shift the time, because that changed too in the law
| (from 02:00LST to 03:00LDT and 02:00 LDT to 01:00LST before, to
| 02:00LST to 03:00LDT and 02:00LDT to 01:00LST after the
| changes).
|
| Took me over 4 fvcking weeks to implement this in Go (due to
| lack of parsers), and I hate Amazon for this to this date.
|
| PS: Write your own Datetime parser, this will help you realize
| how psychotic the human species is when it comes to
| "standards". After all this I'm in huge favor of the Moon Phase
| based International Fixed Calendar [2]
|
| [1]
| https://en.wikipedia.org/wiki/Determination_of_the_day_of_th...
|
| [2] https://en.wikipedia.org/wiki/International_Fixed_Calendar
| GoblinSlayer wrote:
| Reporting of cybersecurity incidents are easily late by a
| month or more, time zones are well below the rounding error.
| You will be more accurate to display it as YYYY+-6month.
| kyawzazaw wrote:
| Corporations and government certainly want people who can
| execute things that are easy, but reliably and consistently
| gjm11 wrote:
| I find this a perplexing comment in view of the fact that
| almost all of the linked article is in fact about how the
| author wrote his own date parsing library; the "never do it"
| bit is _just a couple of lines at the start_ and so far as I
| can tell is mostly there for fun.
|
| (In particular, at no point does the article actually _argue_
| for not writing your own date parsing library. It just says, in
| essence, "Never do it. I did it. Here's what I did and why.")
| kurikuri wrote:
| > When ever i see "never implement your own...", i know i want
| to implement it myself.
|
| Doing stuff for learning is useful, and the intent behind this
| general phrase is to not 'implement your own' something which
| is both hard and critical in a production environment. I work
| in cryptography (for security purposes) and have implemented
| quite a few things myself to learn, but I still use stable,
| field tested, and scrutinized crypto for any actual use.
|
| > 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.
|
| Only wanting to do hard things limits yourself quite a bit:
| what about things which seem easy but could be improved? I
| worked in a non-tech related medical manufacturing job for a
| bit and took time to learn the process and tools. Afterward, I
| implemented a few tools (using what my coworkers (who have no
| programming or IT experience) have available to them: Excel and
| the VBA on the lab computers) to help them prep inventory lists
| which they have been doing by hand. Doing it by hand took them
| 3 hours as a group (and the first shift had to do this every
| morning), which my tool did in 5 seconds with a single button
| click. They still use it to this day, about a decade later.
|
| This wasn't something 'hard:' I glued a few files together,
| grouped a list by a filter, sorted the groups by a column, and
| made a printout which was easy to read and mark on as they went
| about their day. However, my coworkers didn't even know this
| was possible until someone came in with a different skill set,
| learned what they did (by doing the job well for months) and
| then made a solution.
|
| You must be careful with doing only 'hard' things. It requires
| other people to identify what is hard! In addition: crackpots
| do only hard things and believe they find better solutions than
| what exists so far (without consulting or learning about what
| has been done). Interesting people learn about things as they
| are (with the humility of knowing that they are not experts in
| most things) and tries to improve them using the knowledge they
| already have.
|
| Don't waste your time rolling your own crypto when you could do
| the _actual_ hard thing and identify unaddressed space to make
| careful and considered improvements.
| mikepurvis wrote:
| Some things are good hard, the kind of hard that's driven by an
| interesting domain, going deep with well-architected tools or
| systems, learning lots of cool stuff.
|
| I expect datetime-adjacent code is basically the opposite of
| all of this. All the hard parts are driven by fiddly adherence
| to real-world geography, politics, physics/astronomy, etc.
| There's no underlying consistency from which a sane model can
| be extracted, it's just special cases and arbitrary parameters
| all the way down.
|
| I'm up for a challenge of course, but all else being equal, I'm
| happy to leave work that is the "bad hard" to others.
| bapak wrote:
| Correct. It's not hard, just stupidly time consuming to the
| point of being unable to ever produce anything that works 70%
| of the time.
|
| I hate anyone who will attempt to craft their own 10-lines
| line parser and then ignore that it fails 4 times a day. Just
| use the damn library. Thank you.
|
| Write it for fun, but don't ship it. You're wasting
| everyone's time with your _craft._
| yes_man wrote:
| Reminds me of this passage from Postgres documentation:
|
| "As an example, 2014-06-04 12:00 America/New_York represents
| noon local time in New York, which for this particular date
| was Eastern Daylight Time (UTC-4). So 2014-06-04 12:00 EDT
| specifies that same time instant. But 2014-06-04 12:00 EST
| specifies noon Eastern Standard Time (UTC-5), regardless of
| whether daylight savings was nominally in effect on that
| date. ... To complicate matters, some jurisdictions have used
| the same timezone abbreviation to mean different UTC offsets
| at different times; for example, in Moscow MSK has meant
| UTC+3 in some years and UTC+4 in others."
|
| Parsing datetimes indeed sounds like a challenge in
| collecting, knowing and maintaining all these warped out
| standards and compromises. "Bad hard" is a great description
| nicoburns wrote:
| > 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.
|
| You can absolutely do these things. What you need to be aware
| of is that in most cases maintaining these things to a
| production quality level is full-time job for a talented
| engineer. So you shouldn't attempt these IF:
|
| - You have a higher-level aim you are also trying to achieve
|
| - You need a production quality implementation
|
| If one of those isn't the case then knock yourself out.
| DonHopkins wrote:
| It's so tempting to tell you "never implement your own html
| parser using regular expressions" just to make you do it.
|
| I triple dog dare you!
|
| https://www.youtube.com/watch?v=mc6pk2FRhbA
| drewcoo wrote:
| There's hard and then there's "there are so many unexpected
| edge cases you'll surely be cut if you touch that code," which
| not fun-hard.
|
| This is the latter.
| 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.)
| MathMonkeyMan wrote:
| I'd be interested in seeing the Scheme code if it's open
| source!
| 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.
| deadbabe wrote:
| Of course I won't write my own, AI will just write it for me.
| ayaros wrote:
| I will now post the relevant Tom Scott video:
| https://www.youtube.com/watch?v=-5wpm-gesOY
|
| I tried it. I will never try again unless I take, like, six
| months to plan out how the system will work before I even write a
| single line of code.
| deepsun wrote:
| Nothing came close in quality to Joda-time from Java (later
| adopted with small fixes as "java.time" built-in). Why not using
| js-joda port?
| yas_hmaheshwari wrote:
| I never knew that js-joda existed. I love Joda library.
|
| Its surprising that date / time parsing is screwed in multiple
| languages
| spankalee wrote:
| As for this aside:
|
| > As an aside, this search has made me tempted to ask: do we need
| to keep Dual publishing packages? I prefer ESM over CJS but maybe
| just pick one?
|
| Pick ESM. CJS doesn't work in browsers without being transformed
| to something else. Node can require(esm) now, so it's time to
| ditch CJS completely.
| userbinator wrote:
| You're right, you should never need a library but just a
| "sscanf("%04d-%02d-%02d..." ;-)
|
| IMHO needing to handle multiple, possibly obscure, date formats
| simultaneously is nearly never a problem in practice.
| vivzkestrel wrote:
| what is your issue with dayjs?
| danneezhao wrote:
| Great writeup! Your journey perfectly captures the universal
| developer dilemma: "Never roll your own X... until you absolutely
| must."
|
| The bundle size reductions are impressive (230kB client-side
| savings!), and your RFC 9557 alignment is a smart forward-looking
| move. Two questions:
|
| Edge cases: How does your parser handle leap seconds or pre-1582
| Julian dates? (e.g., astronomical data) Temporal readiness: Will
| @11ty/parse-date-strings become a temporary polyfill until
| Temporal API stabilizes, or a long-term solution? Minor
| observation: Your comparison table shows Luxon supports YYYY-MM-
| DD HH (space separator) while RFC 9557 doesn't - this might break
| existing Eleventy setups using space-delimited dates. Maybe worth
| an explicit migration note?
|
| Regardless, fantastic work balancing pragmatism and standards.
| The web needs more focused libraries like this!
| xingwu wrote:
| Thank you for sharing.
|
| I like such subtle branding. I will try 11ty when I need a static
| site generator.
|
| All engineers please follow this example when you want to promote
| your product, even when you don't want to promote your product.
| fsckboy wrote:
| > _Consider "200". Is this the year 200? Is this the 200th day of
| the current year? Surprise, in ISO 8601 it's neither -- it's a
| decade, spanning from the year 2000 to the year 2010. And "20" is
| the century from the year 2000 to the year 2100._
|
| there is so much wrong with this paragraph, it's a nest of people
| who shouldn't work on date parsing. there is no way 200 is any
| kind of date, but if you're going to insist it is, 2000 to 2010
| is 11 years unless "to" means "up to but not including" in which
| case it should say 2001 to 2011 if you want to refer to the 200th
| decade, since decade 1 was 1AD through 10AD...
|
| there is no saving this post
| tobyhinloopen wrote:
| I agree, "200" is just "NotADate". I like JS-Joda's date
| formatting.
| eterm wrote:
| > 2000 to 2010 is 11 years
|
| This is obviously wrong by induction.
|
| If 2000 to 2010 is 11 years, then:
|
| 2000 to 2009 would be length 10 years
|
| ...
|
| 2000 to 2001 would have length 2 years
|
| and finally 2000 to 2000 would be a span lasting "1 year".
|
| But any span with the same start and end point must have length
| zero, it's nonsensical to have a system without that property.
|
| As for the spec, ISO 8601 defines a decade as a period of 10
| years starting with a year divisible by 10 without a remainder.
|
| Decade 1 is year(s) 10 through 19.
| fsckboy wrote:
| > _any span with the same start and end point must have
| length zero_
|
| "a year" is not a point, it's a span. so is a decade.
|
| > _Decade 1 is year(s) 10 through 19_
|
| but the property you are trying to describe goes hand in hand
| with 0-based indexing, and thus we see that ISO Decade 0 is
| >sad tuba< 9 years long
| eterm wrote:
| It is actually 10 years long by how ISO 8601 defines a
| decade.
|
| Also it's worth noting here that ISO 8601 has a year zero,
| which equates to 1BC in historical terms.
| ozgrakkurt wrote:
| Maybe the title should be "it is difficult to write a date
| parsing library"
|
| "Never write your own x" kind of titles come off as arrogant and
| demotivating.
|
| Maybe some other person will write an excellent date parsing
| library that will be better than current ones? Maybe they think
| it is worth to spend some time on it?
|
| These kinds of hard things tend to have libraries that are
| extremely bloated because everyone uses one library, and that one
| library has to work for everyone's use case.
|
| You can see this in the post too, not everyone needs to be able
| to parse every single date format.
| dylan604 wrote:
| I'll stand by the never roll your own crypto, but never roll
| your own date parsing library that your DIY crypto library
| depends would be uber scary
| aussieguy1234 wrote:
| Almost never...
|
| There may be some obscure cases.
|
| Like for example, lets say you are writing very performance
| sensitive code where nanoseconds count. All of the date parsing
| libraries available for the language you are writing are too slow
| for your requirements. So you might roll your own lighter weight
| faster one.
| Animats wrote:
| I requested an ISO 8601 date parser in the Python "datetime"
| library in 2012.[1] "datetime" could format into ISO 8601, but
| not parse strings. There were five ISO 8601 parsers available,
| all bad. After six years of bikeshedding, it was was fixed in
| 2018.
|
| That's what it took to _not_ write my own date parsing library.
|
| [1] https://github.com/python/cpython/issues/60077
| motorest wrote:
| > That's what it took to not write my own date parsing library.
|
| If you wrote your own date parsing library, there would be six
| ISO 8601 parsers available, all bad.
|
| You should feel grateful for not having wasted your time.
| xaer wrote:
| I wrote the ethlo ITU library because I was annoyed with the lack
| of performance and large amount of ceremony to parse and format
| standard timestamps in RFC-3339 format in Java. It is somewhat
| more extensive now, and is used in other libraries. Ask me
| anything!
| bryanrasmussen wrote:
| so, anyway, never do this which I did and have great technical
| reasons why it had to be done for my language and needs.
| jillesvangurp wrote:
| IMHO, ISO 8601 as a standard is way too broad and unspecific. ISO
| 8601 is way too messy. Telling somebody that they need to parse
| an ISO 8601 date time is not enough information to do the job.
| Which variant is it? Does it include the time part. IMHO allowing
| the full range of ISO 8601 dates and times in a data format is
| usually a mistake. You want to be more specific.
|
| There's a need for a standard that locks down the commonly used
| variants of it and gets rid of all the ambiguity.
|
| For me, timestamps following this pattern 'YYYY-MM-
| DDThh:mm:ss.xxxxxZ' is all that I use and all my APIs will
| accept/produce. It's nice that other legacy systems are available
| that don't normalize their timestamps to UTC for whatever reason,
| that consider seconds and fractions of a second optional, etc.
| But for unambiguous timestamps, all I want is this. It's fairly
| easy to write a parser for it. A simple regular expression will
| do the job. Of course add unit tests. Technically the Z is
| redundant information if we can all agree to normalize to UTC.
| Which IMHO we should. In the same way the T part and separators
| are redundant too. But they are nice for human readability.
|
| You can use datetime libraries that are widely available to
| localize timestamps as needed in whatever way is required
| locally. But timestamps should get stored and transmitted in a
| normalized and 100% unambiguous way.
|
| It's only when you get into supporting all the pointless and
| highly ambiguous but valid variants of ISO 8601 that parsing
| becomes a problem. There's actually no such thing as a parser
| that can parse all valid variants with no knowledge of which
| variant is being used. There are lots of libraries with complex
| APIs that support some or all of the major and minor variants of
| course. But not with just one function called parse().
|
| I think the main challenge with ISO 8601 is that it never called
| out this variant as a separate thing that you should be using.
| This really should be its own standard. And not using that would
| be a mistake. ISO 8601 is what happens when you do design by
| committee.
| ttiurani wrote:
| > You can use datetime libraries that are widely available to
| localize timestamps as needed in whatever way is required
| locally. But timestamps should get stored and transmitted in a
| normalized and 100% unambiguous way.
|
| If by "timestamp" you mean past dates and deterministic future
| dates, then agreed. (Although I prefer unix epoch in ms for
| those, to be able to use integers and skip string parsing steps
| completely.)
|
| But if your unlucky enough to need to handle future dates,
| especially "clock on the wall" ("let's meet in Frankfurt on
| July 26th 2029 at 1pm"), then you just can't know the timezone.
| The reasons can be many political ones, but especially in this
| case there's a high probability that EU will remove daylight
| saving time by then.
|
| So in those cases, if you want to be correct, you'd need to
| include the geolocation in the stored timestamp.
| jillesvangurp wrote:
| > Frankfurt on July 26th 2029 at 1pm
|
| That's a localized date and time. And it shouldn't be what
| you store but what you present based on the user's
| preferences. The same calendar event would be completely
| different in the calendar of a tourist visiting Frankfurt.
| And calendar invites of course can have multiple participants
| that each want their date times localized to their time zone
| and locale. So the best way to do that is to store the time
| zone in a 100% normalized, unambiguous way that is then
| transformed into whatever matches the user's preferences as
| part of the presentation logic.
|
| In the same way, place names are localized. The French would
| spell Frankfurt as Francfort, for example. Location should be
| a separate field. And it implies nothing about the locale
| that should be used for presenting the timestamp or the
| timezone that should be used. Because Frankfurt is a rather
| international town and some might prefer MM DD YY instead of
| DD MM YYYY. Not to mention the use of am/pm vs. 24 hour time.
| And of course it has a big airport that people use to travel
| to pretty much all time zones on the planet. Hard coding all
| that in a timestamp is a mistake. Because now you need
| needlessly complex parsing logic and transformation logic to
| fix that mistake. Which is what this article is about.
| ttiurani wrote:
| > That's a localized date and time.
|
| Note that I'm not arguing against storing the numeric part
| in a consistent format, of course you should. My point is
| that right mow in 2025 you don't know the timezone.
|
| E.g. if you write that as the zones are now, it would be
| "2029-07-26T11:00:00.000Z", but if the timezones change,
| then when a person is looking at their calendar in 2029,
| they will be an hour early or late to the meeting.
|
| So it's not about presentation of the timestamp, it's that
| the timestamp does not match what the user meant.
|
| > In the same way, place names are localized.
|
| I beg to disagree. All spellings refer to the same
| phyysical place, but you can't guarantee my example
| timestamp description and a simple ISO time representation
| without a geolocation will refer to the same singular point
| in time.
| skrebbel wrote:
| I agree with the gist of your comment but I think you're
| using the wrong words.
|
| A time zone, as the name implies, is a zone, a place. The
| most common way to indicate a timezone is a
| continent+city combo that is both politically and
| geographically close, so it's unlikely to change.
| Therefore, I very much know the timezone of Frankfurt,
| both today and in the reasonably close future, namely
| "Europe/Berlin".
|
| You're talking about the timezone _offset_. You're right,
| don't store that for future local dates. Store the
| timezone.
|
| (Or just the exact location, but then you need a way to
| map location -> offset if you ever want to do time math
| on it, and the IANA Continent/City format strikes a nice
| pragmatic balance there)
| ttiurani wrote:
| Well, not really. :) Timezones are the whole area that
| has the same time. So "Europe/Berlin" and "Europe/Rome"
| right now can be used in user-facing help texts to make
| the timezone understandable, but those cities might not
| be in the help text in the future. That's because:
|
| "Each time zone is defined by a standard offset from
| Coordinated Universal Time (UTC)."
| (https://en.m.wikipedia.org/wiki/Time_zone)
|
| So the offset _is_ the timezone.
|
| That's why I stand with my original point: if you want to
| support "clock on the wall" future dates, a geolocation
| is needed. And given that Germany was two countries in
| the recent past and Frankfurt and Berlin were in
| different countries, I wouldn't solve this by picking a
| city from the help text that's currently closest to the
| timezone, but instead use the actual geolocation of the
| event.
|
| P.s. All this is, of course, for 99.99% of the cases a
| complete overkill, and as said, I haven't had issues in
| using unix epoch for all dates. But just wanted to say
| that timestamps aren't as simple as I felt was suggested
| in the first comment.
| skrebbel wrote:
| The way I understand it, Continent/City names aren't for
| pretty dropdowns or help texts (in fact, I'd wager
| they're kinda meh for that). They're the least bad way
| people have come up with to store and communicate
| timezones with future local dates, that doesn't require
| online geolocation. You're right that geolocation is the
| best. But offsets aren't a close second, like I feel your
| comments suggest - they're just a bad idea. To suggest
| that a timezone "is" an offset, while technically correct
| if you disregard future changes, is actively harmful to
| helping people write code with fewer timezone bugs.
|
| Use IANA Continent/City names. They're great, all proper
| datetime libs support them, your OS supports them,
| they're _reasonably_ human readable and completely
| machine readable. They 're better for storage than
| offsets (or terrible future-incompatible terms like CET)
| in every way.
|
| Really the entire timezone debacle can IMO be summarized
| as:
|
| - for datetimes in the past, store UTC. convert from/to
| local in the UI; just assume the system/browser locale is
| the one unless you know otherwise.
|
| - for global datetimes in the future, eg comet passings
| and the likes, same thing.
|
| - for local datetimes in the future, at some "wall clock
| time in a place", store localtime + an IANA
| Continent/City combo, and keep your servers' tzdata files
| reasonably updated.
|
| It never makes sense to store or communicate offsets. It
| hardly ever makes sense to do geolocation unless you
| think you think the chance that Berlin moves to a
| different country than Frankfurt is bigger than the
| chance that you lose access to up-to-date geolocation
| information.
|
| Note that the above implies that the option for ISO date
| strings to include offsets (or words like "CET") is, IMO,
| nearly always the wrong choice. For past dates (ie 99.9%
| of dates stored by computer systems) just use UTC, and
| for future dates, IANA timezone names are strictly
| better.
| GoblinSlayer wrote:
| Or in 2027 the Sith Empire could conquer Earth and
| install imperial time system. Good luck with your
| timestamps. Just make your scheduler as a walled garden
| SaaS - no need to exchange timestamps.
| Arrowmaster wrote:
| Ah I have the perfect solution. Let's add GPS coordinates
| to datetime stamps!
|
| Please put the pitchfork away it was only a joke. (Until
| someone actually does this because it makes a twisted
| sort of sense)
| bdhcuidbebe wrote:
| Never say never
| cultureulterior wrote:
| Pity they're dropping week number- it's used so much in Europe.
| ashoeafoot wrote:
| Now i want to make a date format, combined with other data that
| is the ultimate challenger of date parsing.
|
| IntroDuceThing: The ip:port,date/time,longlat string. Oh, yes its
| format is also dependant on the language you encode it in and
| what parts you leave out to be defaulted. .:, is now a valid
| locationdateip
| atoav wrote:
| Well, I did that. And it works flawlessly for a decade now. The
| thing is just that I know and control the context from which the
| dates are being parsed. If you're now like: "Yeah ok if you're
| the one who sends the data being parsed it might be okay", the
| claim of "never do X" is proven wrong if there are specific
| situations where soing X is not only okay, but might be the
| sensible option.
|
| Which is why you should never use the word "never" unless you're
| really sure you can't come up with a situation that is an
| exception.
| stevage wrote:
| They didn't say whether it would have been feasible to just
| extract that one function from the library - sort of manually
| tree-shaking, if you will.
| zelphirkalt wrote:
| The table of listed date formats doesn't look too difficult to
| implement. A quick look at the RFC tells me, that the RFC even
| specifies a grammar, though very incomplete. It would be prudent
| to specify a complete grammar in the RFC of course. Then it would
| be even simpler taking that grammar and translating it to
| whatever library one uses for describing grammars for parsing
| stuff. I really hope all these libraries didn't make silly things
| with regexes ...
| aidenn0 wrote:
| > ... billed as "an extension to the ISO 8601 / RFC 3339" formats
|
| The quote comes from MDN[1], but is wrong on so many levels:
|
| 1. RFC 3339 is not a format; it is a meta-format. It specifies
| properties that any timestring used in internet applications
| should have. One application could require that "T" be used to
| separate the date and the time, while another could require a
| space to be used, and both applications would conform to 3339.
| Using the same parser to parse times and dates from the two
| applications would be incorrect, as "1234-12-12 12:34 ..."
| unambiguously represents the date of December 12, 1234 in the
| former but the time of 12:34 on the same day in the latter.
|
| 2. RFC 3339 is thus not a subset of ISO-8601; there exists a
| subset of ISO-8601 which satisfies RFC 3339, but there also exist
| many timestrings that are not subsets of ISO-8601 which also
| satisfy it (most famously replacing "T" with a space, but that is
| merely an example for which RFC 3339 conforming applications may
| deviate from the ABNF in the RFC for readability).
|
| 3. It is obvious from both #2 and the table in TFA that RFC 9557
| _can 't_ be an extension of ISO-8601 given that there are valid
| ISO-8601 timestrings in the table that are invalid RFC 9557
| timestrings.
|
| 4. This is a minor nitpick, bu RFC 9557 also alters the semantics
| of some RFC 3339 timestrings with regards to offsets. RFC 3339
| specified "Z" (or "z") for the offset being the same as +00:00,
| while 9557 has "Z" being the same as -00:00; the meat of RFC 9557
| is adding suffix-tags to RFC 3339, so I wouldn't quibble with
| calling 9557 an extension of 3339.
|
| 1: https://developer.mozilla.org/en-
| US/docs/Web/JavaScript/Refe...
| dbg31415 wrote:
| Relevant.
|
| https://m.youtube.com/watch?v=-5wpm-gesOY
| cobertos wrote:
| > Most date parsing woes (in my opinion) come from ambiguity:
| from supporting too many formats or attempting maximum
| flexibility in parsing. ... There is a maintenance freedom and
| simplicity in strict parsing requirements ...
|
| Is this the endgame of "be liberal in what you accept, but strict
| in what you output"? You end up supporting an untold amount of
| usage patterns, not even chosen by yourself if you use a library
| like `luxon` to handle the "be liberal" part for you.
___________________________________________________________________
(page generated 2025-07-26 23:01 UTC)