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.
mikepurvis · 2h ago
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.
glibby · 22h ago
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.
kuon · 9h ago
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.
patrick0d · 7h ago
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 · 7h ago
> 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 · 6h ago
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!
Hnrobert42 · 7h ago
>Maybe be careful
Really?
flir · 21h ago
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 · 20h ago
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 · 20h ago
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.
No comments yet
tbrownaw · 15h ago
> 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.
shakna · 16h ago
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.
bdangubic · 16h ago
I write my own, but in production I always use libraries written by some dude from Omaha :)
dylan604 · 12h ago
And that dude is no longer actively maintaining it and you just discovered an issue with it.
cmdlyne2 · 6h ago
> 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).
ramijames · 21h ago
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 · 21h ago
> 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”
ozim · 20h ago
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.
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 · 21h ago
Nah, finding that stuff is what users are for.
mattmanser · 21h ago
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.
zelphirkalt · 6h ago
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.
gmueckl · 21h ago
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.
kulahan · 16h ago
Why would I mature yours and deal with those issues when I can just use the already-mature one?
gmueckl · 13h ago
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.
immibis · 18h ago
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?
bigstrat2003 · 15h ago
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 · 14h ago
Correct date handling (including parsing) can be monumentally important. Imagine an app that reminds people when to take their medications, for example
what · 14h ago
You typically take medication at a set time every day. You don’t need to parse dates for that.
poink · 13h ago
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 · 13h ago
A lot of cryptography relies on dates, time, etc.
motorest · 11h ago
> 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.
chii · 12h ago
> 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 · 12h ago
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 · 11h ago
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 · 9h ago
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 · 11h ago
> 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 · 11h ago
Also as an employee, this forces me to job hop to stay relevant.
pjmlp · 11h ago
Unless you happen to live in cultures where that is looked down upon as not able to keep a job.
pletnes · 4h ago
Meaning you will job hop less, but you still have to weigh the advantage/disadvantage as always.
d_tr · 11h ago
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.
quelsolaar · 11h ago
Your customers will pay more for things that are hard to do. Ask ASML.
motorest · 11h ago
> 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?
seb1204 · 5h ago
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.
bdhcuidbebe · 10h ago
> 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.
bdhcuidbebe · 10h ago
> 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 · 9h ago
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 · 10h ago
Is quelsolaar your employee?
kurikuri · 6h ago
> 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.
leakycap · 22h ago
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.
quelsolaar · 11h ago
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.
ok_dad · 21h ago
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 · 19h ago
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 · 16h ago
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 · 13h ago
> 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 · 15h ago
> 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.
nicoburns · 1h ago
> 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.
avanwyk · 20h ago
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.
stouset · 18h ago
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.
thfuran · 8h ago
>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.
immibis · 18h ago
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.
brianpan · 20h ago
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.
gjm11 · 8h ago
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.")
VohuMana · 21h ago
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.
dracodoc · 19h ago
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 · 12h ago
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.
psychoslave · 12h ago
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.
ozim · 12h ago
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".
d_tr · 11h ago
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.
geocar · 13h ago
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".
cookiengineer · 10h ago
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]
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.
qwertox · 21h ago
This past 22nd of July was the shortest recorded day [0]. How would your library handle this?
Answer: not at all, unless I had to deal with astronomical time to compute locations of celestial bodies with high precision.
cortesoft · 15h ago
No libraries handle this, though
kyawzazaw · 10h ago
Corporations and government certainly want people who can execute things that are easy, but reliably and consistently
david-gpu · 21h ago
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?
rkagerer · 19h ago
Don't forget to roll your own crypto libraries.
djfivyvusn · 18h ago
Yea, date time parsing is probably fine so is rolling your own auth, unicode, font rendering, compilers.
Datetime libs themselves? No thanks.
whoamii · 14h ago
… but if you plan to sell it, don’t build your own billing system!
richardw · 15h ago
Never write your own multi-planetary date/time library in brainfuck.
fsckboy · 22h ago
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 · 21h ago
I exclusively write in C89. I'm a member of the ISO C standard board.
boothby · 20h ago
The confluence of tinker-for-tinkerings'-sake "hackers" and get-rich-quick "hackers" on this site certainly leads to a lot of fun miscommunication.
bobsmooth · 21h ago
Solve new hard things instead of solved hard things.
GoblinSlayer · 4h ago
Most solutions are garbage though, because they evolved accidentally.
dafelst · 19h ago
Or you know, just do what you want
davidw · 1d ago
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"
3cats-in-a-coat · 23h ago
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 · 23h ago
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.
"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 · 18h ago
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 · 12h ago
> 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 · 7h ago
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 · 4h ago
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.
tetha · 22h ago
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 38 hour cycles, and some huge dudes with a trunk in their face are tuned to 356 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 · 22h ago
> 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 · 10h ago
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 · 7h ago
As a native speaker I found it pretty easy to read.
commandlinefan · 21h ago
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 · 23h ago
Vernor Vinge had it figured out in A Deepness in the Sky with the use of kiloseconds, megaseconds, and gigaseconds.
greggyb · 10h ago
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.
BurningFrog · 23h ago
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.
ceejayoz · 22h ago
Seconds are now (in SI) defined as calculated from behavior of cesium-133 atoms.
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 · 12h ago
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 · 7h ago
That clock hasn't actually been built yet and it wouldn't be useful for guiding nuclear missiles.
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.
BurningFrog · 22h ago
You can also define "days" and "years" in terms of that SI definition.
I don't think that helps with the original concern.
ceejayoz · 22h ago
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 · 22h ago
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 · 22h ago
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 · 5h ago
> "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 800× 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.
gleenn · 23h ago
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 · 22h ago
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 · 22h ago
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 · 22h ago
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.
GoblinSlayer · 3h ago
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.
BurningFrog · 12h ago
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.
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
Terr_ · 20h ago
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 · 13h ago
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.
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".
dmoy · 23h ago
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 · 19h ago
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.
Arainach · 23h ago
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.
devilbunny · 23h ago
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 · 23h ago
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 · 22h ago
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 · 22h ago
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.
amelius · 22h ago
Well, that problem exists now too, but everybody sticks their head in the sand.
cobertos · 1h ago
> 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.
QuadmasterXLII · 1d ago
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.
kaoD · 1d ago
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".
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 )
keeganpoppen · 23h ago
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 · 22h ago
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.
geocar · 12h ago
> 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 (30時) 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™ either, but I know enough to know that every existing solution is wrong in some way that can cause real harm.
8organicbits · 1d ago
> 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.
kriops · 1d ago
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 · 1d ago
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.
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.
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.
senfiaj · 1d ago
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 · 23h ago
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 · 12h ago
$ 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 Jän 2003 00:00:00 EET
$ LANG=zh_HK.utf8 date --date="01/02/03"
2003年01月02日 星期四 00:00:00 EET
dragonwriter · 23h ago
> 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.)
happytoexplain · 1d ago
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.
jack_pp · 1d ago
Pretty sure they force the user into that format so that shouldn't be an issue
PaulHoule · 1d ago
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.
BurningFrog · 23h ago
Normal/"legal" dates are not timestamps or related to timezones, and this fact will eternally be rediscovered as long as humans write software.
legulere · 21h ago
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).
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 · 16h ago
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).
kccqzy · 1d ago
> 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.
SoftTalker · 1d ago
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 · 1d ago
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 · 1d ago
Well, for hardcore chronology Julian dates are what you do.
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.
No comments yet
happytoexplain · 1d ago
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.
pavel_lishin · 23h ago
> 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 · 22h ago
I disagree with that. And furthermore it's not parsing. It's converting between a single integer and a tuple of three integers.
habibur · 23h ago
> 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.
kccqzy · 22h ago
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://github.com/kccqzy/smartcal/blob/9cfddf7e85c2c65aa6de...
oneshtein · 12h ago
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.
jerf · 23h ago
"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.
shadowgovt · 22h ago
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.
dlachausse · 1d ago
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.
mattkrause · 1d ago
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.
Tyr42 · 1d ago
I've had to click back once per year old I am sometimes. I'd rather just type my birthday.
jillesvangurp · 11h ago
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 · 10h ago
> 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 · 8h ago
> 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 · 7h ago
> 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 · 6h ago
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 · 4h ago
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:
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 · 3h ago
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 · 2h ago
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 · 6h ago
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)
neilv · 21h ago
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 · 4h ago
I'd be interested in seeing the Scheme code if it's open source!
Animats · 12h ago
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.
> 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.
aidenn0 · 4h ago
> ... 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.
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.
They might be subtracting taking first 4 digits and the subtracing yyyy-yyyy, mm-mm and dd-dd.
dguest · 9h ago
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 · 1d ago
In mainframes, Julian dates are popular for that reason. YYDDD (day of year).
When is 30 days after today? 25206+30
alexanderchr · 21h ago
Maybe I’m missing something but then what is 30 days after Christmas? 25389?
mpyne · 20h ago
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 · 15h ago
What happens when you want to add more than 365 days to a date, then?
takinola · 22h ago
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.
alex_c · 21h ago
Except you do still have to think about time, no matter what… Libraries will help with the really messy details, but even the high level requirements have a lot of pitfalls.
“Simple” example that anyone who’s ever worked on a scheduling application will probably be familiar with:
“Get a list with all of today’s events.”
Well, whose “today” (timezone) are we talking about? Server, client, setting in the user account? Or none of the above, and actually timezone at the physical location of the event, if there is one?
And what does “today” mean, anyway? Truncate the date? 00:00-23:59? Business hours?
And what does “today’s event” even mean? Events can cross midnight… Does an event need to start today? End today? Both? Can events span multiple days?
The fun never ends!
ori_b · 21h ago
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 · 10h ago
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
servercobra · 22h ago
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.
fleebee · 5h ago
moment.js has been deprecated for, what, close to 5 years now? I wouldn't recommend choosing it over any of the modern alternatives.
cbm-vic-20 · 22h ago
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).
whatever1 · 22h ago
It’s because it is not systematic historically. It’s a system full of edge cases
hnuser123456 · 22h ago
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()
shadowgovt · 22h ago
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).
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 · 14h ago
> 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 · 17h ago
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.
colesantiago · 1d ago
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!
jimmaswell · 1d ago
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 · 23h ago
I couldn't agree more. I have no idea why the moment devs are trying to kill moment.
fsckboy · 12h ago
>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 · 11h ago
I agree, "200" is just "NotADate". I like JS-Joda's date formatting.
eterm · 9h ago
> 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 · 3h ago
>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
zelphirkalt · 6h ago
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 ...
xaer · 11h ago
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!
danneezhao · 14h ago
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!
senfiaj · 1d ago
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 · 21h ago
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 · 19h ago
At least the real input value is in YYYY-MM-DD. Also the date picker will show the day in it's calendar UI.
ozgrakkurt · 12h ago
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 · 12h ago
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
jedberg · 1d ago
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.
9dev · 23h ago
> 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 · 23h ago
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.
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.
ashoeafoot · 10h ago
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
stevage · 7h ago
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.
the__alchemist · 1d ago
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 · 1d ago
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 · 1d ago
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.
endoblast · 20h ago
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).
> 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.
xingwu · 13h ago
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.
macintux · 20h ago
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.
I’d like to get back to it. If nothing else, I dearly miss using Erlang.
wood_spirit · 1d ago
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! :)
champtar · 20h ago
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.
Pity they're dropping week number- it's used so much in Europe.
deepsun · 17h ago
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 · 6h ago
I never knew that js-joda existed. I love Joda library.
Its surprising that date / time parsing is screwed in multiple languages
bryanrasmussen · 11h ago
so, anyway, never do this which I did and have great technical reasons why it had to be done for my language and needs.
CurtHagenlocher · 23h ago
In 2009 I made a note that Excel's main date parsing function was over 1000 lines of code -- not including helpers.
fitsumbelay · 1d ago
before I even read the post lemme just say "too late, friend. faaaaar too late ..."
Hizonner · 20h ago
Never mess with cryptography, times, Unicode, or floating point.
fHr · 20h ago
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 .
atoav · 7h ago
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.
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.
aussieguy1234 · 12h ago
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.
micromacrofoot · 1d ago
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 · 1d ago
Add phone numbers, email addresses and human names to the list.
peheje · 22h ago
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.
micromacrofoot · 22h ago
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 · 14h ago
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 · 5h ago
You'd be surprised how often two fields mess up names if you live in a place that has any amount of immigration.
econ · 23h ago
Just validate the registration form? Surely this is a solved problem?
Uhhh...
vivzkestrel · 14h ago
what is your issue with dayjs?
danesparza · 1d ago
I mean. Yes. Don't write your own date parsing library. Unless you want to go nuts.
Of course I won’t write my own, AI will just write it for me.
aaroninsf · 21h ago
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...
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.
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.
Don't write your own OS does not mean do not contribute to something like the linux kernel.
To the people reading this, please don't just disagree with an "obvious counterexample". Explain why!
Really?
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.
See the number of unit tests in the Linux kernel, for example.
You could run a fuzzer against two libraries at the same time to find discrepancies....... hmm. That might actually be a good exercise.
No comments yet
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.
You can have reasonable confidence that here there be dragons, but not so much that your assumptions about something will hold.
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).
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.
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”
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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?
You should try instead.
I brought jugglers balls for my team and in a few weeks we had 4 or 5 fluent.
Then how do you expect them to learn?
Good luck getting more blood out of that stone, smh.
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.
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.
There is a difference between things that are difficult and things that just take a lot of work.
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?
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"
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.
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.
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.
But please at least file the bug first.
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.
Just, why.
(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.")
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.
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.
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.
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.
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".
OTOH writing, e.g., your own renderer could cause some funny display at worst and maybe some unnecessary effort.
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".
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
[0] https://www.space.com/astronomy/earth/earth-will-spin-faster...
Datetime libs themselves? No thanks.
all the people who say C is not safe have downvoted me for quoting them
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/CallARabbitASmee...
"Armageddon" actually. Poignant because it's a movie about a nuclear ballistic submarine. But not a particularly non-English word.
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 38 hour cycles, and some huge dudes with a trunk in their face are tuned to 356 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.
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.
You couldn’t translate that novel to Italian or Finnish, or any language with proper phonetical spelling.
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.
That doesn't make it unusable as a cross galactic time unit, and I think the same goes for years and hours.
https://en.wikipedia.org/wiki/Caesium_standard
https://en.wikipedia.org/wiki/Nuclear_clock
I don't think that helps with the original concern.
"Our dates start x trillion rotations of pulsar y ago and our unit is defined as z wiggles of cesium" is a starting point.
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.)
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 800× 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.
(... 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).
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.
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
> 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.
https://babylon5.fandom.com/wiki/Measurements_of_Time
Aliens use phrases like " 2 of your Earth days "
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."
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.
The first is significantly easier as it requires remembering only a single offset and then going with societal conventions.
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.
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.
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
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 )
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 (30時) 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™ either, but I know enough to know that every existing solution is wrong in some way that can cause real harm.
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.
https://ijmacd.github.io/rfc3339-iso8601/
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.
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.)
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.
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
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.
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.
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.
No comments yet
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.
Didn't the article explicitly tell us not to write our own date parsing library?
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.
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.
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.
I'd hate it less if typing updated the widget.
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.
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.
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.
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.
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)
"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.
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.
Please put the pitchfork away it was only a joke. (Until someone actually does this because it makes a twisted sort of sense)
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.)
That's what it took to not write my own date parsing library.
[1] https://github.com/python/cpython/issues/60077
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.
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...
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.
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?
2025-02-01 - 2025-01-31 = 20250201 - 20250131 = 70
When is 30 days after today? 25206+30
“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!
You just need to understand how time works if you write code handling time.
And still, you regularly run into issues, because our API or a third party did something silly
https://learn.microsoft.com/en-us/dotnet/api/system.globaliz...
https://learn.microsoft.com/en-us/windows/apps/design/global...
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.
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.
I encourage everyone to learn how to parse the japanese calendar format.
The more people know the better!
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.
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
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.
"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
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!
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
“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.
Make your own load balancer software
Make firewall software
Make a date parsing library
Attempt to verify an email with a regular expression.
Accept people's names
Anything
IMHO needing to handle multiple, possibly obscure, date formats simultaneously is nearly never a problem in practice.
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
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).
> 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.
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.
https://github.com/macintux/jam
I’d like to get back to it. If nothing else, I dearly miss using Erlang.
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! :)
https://m.youtube.com/watch?v=-5wpm-gesOY
https://stackoverflow.com/a/49185071/59087
Its surprising that date / time parsing is screwed in multiple languages
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.
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.
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.
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.
explains the naming conventions of every culture on the planet
Uhhh...
https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b...
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...