Hacker News

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.

> 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.

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.

> 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.

> 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.

> 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.

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.

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.

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.")

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.

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.

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.

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".

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.

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".

I feel obligated to comment on this.

Due to my work I rely on web scraped data for cybersecurity incidents. For Amazon Linux, they are disclosed with the fvcked up US datetime format (Pacific Time) and not in ISO8601 formatted strings which could imply Juliet/Local time.

In 2007 there was a new law that changed when Pacific Time enters/leaves Daylight Saving Time. Instead of making this fixed by a specific Day of a specific Month in numbered form like say "YYYY-03-01 to YYYY-10-01", they literally wrote the law quoting "first Sunday of April" to "last Sunday in October". Before 2007 it was "Second Sunday in March" to "first Sunday in November".

I'm not making this shit up, go ahead and read the law, come back and realize it's even more complex for other timezones, because some nations seem to make fun of this by going to +14:00 hours and -11:30 hours depending on the president's mood on Christmas or something.

In order to find out the Day of a specific calendar date, there's this cool article about Determination of the day of the week [1] which is quite insane on its own already. There is no failsafe algorithm to do that, each method of determining the day of the week has its own tradeoffs (and computational complexity that is implied).

Then you need to get all Sundays of a month, count the right one depending on the year, map back the date to ISO8601 and then you know whether or not this was daylight saving time they're talking about. Also make sure you use the correct local time to shift the time, because that changed too in the law (from 02:00LST to 03:00LDT and 02:00 LDT to 01:00LST before, to 02:00LST to 03:00LDT and 02:00LDT to 01:00LST after the changes).

Took me over 4 fvcking weeks to implement this in Go (due to lack of parsers), and I hate Amazon for this to this date.

PS: Write your own Datetime parser, this will help you realize how psychotic the human species is when it comes to "standards". After all this I'm in huge favor of the Moon Phase based International Fixed Calendar [2]

[1] https://en.wikipedia.org/wiki/Determination_of_the_day_of_th...

[2] https://en.wikipedia.org/wiki/International_Fixed_Calendar

Corporations and government certainly want people who can execute things that are easy, but reliably and consistently

This past 22nd of July was the shortest recorded day [0]. How would your library handle this?

[0] https://www.space.com/astronomy/earth/earth-will-spin-faster...

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?

Don't forget to roll your own crypto libraries.

Yea, date time parsing is probably fine so is rolling your own auth, unicode, font rendering, compilers.

Datetime libs themselves? No thanks.

… but if you plan to sell it, don’t build your own billing system!

Never write your own multi-planetary date/time library in brainfuck.

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

Solve new hard things instead of solved hard things.

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.

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".

Well, that problem exists now too, but everybody sticks their head in the sand.

> 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.

I like how Temporal[0] does this. What you were dealing with is Temporal.PlainDate[1], i.e. a date with a calendar associated but no time or timezone (might be due to being implied but also might be irrelevant, like in birthdates).

Temporal has other cool types, each with distinct semantics:

- Instant: a fixed point in time with no calendar or location. Think e.g. "the user logged in at X date and time" but valid across the world for any timezone or calendar system. This is what we usually use "Unix UTC timestamps" for.

- ZonedDateTime: like an Instant but associated with a particular calendar and location. Think an Instant but rendered "real" into a calendar system and timezone so the user can see a meaningful time for them.

- PlainDate: already discussed. Think e.g. birthdates.

- PlainTime: think "run task every day at 6:30pm".

- PlainDateTime: like an Instant but associated with a calendar system, but no timezone. Think e.g. what a user would insert in a datetime picker, where the timezone is implied instead of explicitly selected.

- PlainYearMonth: think e.g. "we'll run our reports during October 2025".

- PlainMonthDay: think e.g. "my birthday is June 13".

- Duration: think e.g. "the task ran for 3hrs 30min".

Also see its important concepts[2].

[0] https://tc39.es/proposal-temporal/docs/

[1] https://tc39.es/proposal-temporal/docs/#Temporal-PlainDate

[2] https://tc39.es/proposal-temporal/docs/timezone.html

> 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.

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.

Normal/"legal" dates are not timestamps or related to timezones, and this fact will eternally be rediscovered as long as humans write software.

If you store it just as a string it means that you cannot do anything useful with it like age-dependent logic or you just pass on parsing logic to users of the field.

FHIR in my opinion has a pretty good system for dates (including birthdates): YYYY, YYYY-MM, or YYYY-MM-DD. (Not knowing your exact birthday is common for some countries).

https://build.fhir.org/datatypes.html#date

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.

> 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.

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.

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.

I'd be interested in seeing the Scheme code if it's open source!

> 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.

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!

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.

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

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.

moment.js has been deprecated for, what, close to 5 years now? I wouldn't recommend choosing it over any of the modern alternatives.

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).

It’s because it is not systematic historically. It’s a system full of edge cases

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).

Wait so one day over the new year is

2025-01-01 - 2024-12-31 = 20250101 - 20241231 = 8870

i.e. 90 months and 10 days

or 7 years 6 months and 10 days

How is that the same thing as one day?

In mainframes, Julian dates are popular for that reason. YYDDD (day of year).

When is 30 days after today? 25206+30

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.

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.

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!

I agree, "200" is just "NotADate". I like JS-Joda's date formatting.

> 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.

I couldn't agree more. I have no idea why the moment devs are trying to kill moment.

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

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

> Attempt to verify an email with a regular expression.

  .+@.+

Is parsing HTML with regexes Ok?

Roll your own encryption

Accept people's names

Anything

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.

I never knew that js-joda existed. I love Joda library.

Its surprising that date / time parsing is screwed in multiple languages

Add phone numbers, email addresses and human names to the list.