
Insane complexity of calendrically correct date and time operations - mtmail
http://yourcalendricalfallacyis.com/
======
josecastillo
I've encountered just about every item on this list working on my Apple Watch
complication, Better Day[1], which supports 11 calendar systems in 21
languages. The funny thing is, the last item on this list — always use ICU
through the NSCalendar API — is the exact conclusion I arrived at, and one
that I preach to anyone who will listen.

Especially with modern Swift syntax, complex questions like "what's the
current day of the year" end up having simple, almost poetic answers like
"calendar.ordinality(of: .day, in: .year, for: date)". And you can trust that
they are correct for every calendar and every locale. Usually. [2]

[1] [https://itunes.apple.com/us/app/better-day-a-
complication/id...](https://itunes.apple.com/us/app/better-day-a-
complication/id1052023515?ls=1&mt=8)

[2] [https://www.joeycastillo.com/notes/2016/09/18/of-crescent-
mo...](https://www.joeycastillo.com/notes/2016/09/18/of-crescent-moons-and-
calendars/)

~~~
tewt
I only skimmed your article, but are you sure that's right? There must have
been at least several date adjustments before your app was release yet the
system time maintained the correct date. Presumably it'll correct afterwards,
invalidating the date offset.

~~~
josecastillo
The thing to keep in mind is that before the sighting, the months are pre-
calculated for when the first crescent moon should rise over Mecca. So a
change only affects the single month where the observation differed. For
example, if you're expecting to see the first crescent moons on October 10,
November 9 and December 8, but you didn't see the first one until October 11,
that doesn't push the moon sightings out for the rest of the year. It just
means that the month you thought would end on October 9 will have an extra
day, and the month you thought would start on October 10 will start a day
later (and as a result will be a day shorter).

Future months are still totally fine; the date offset is just a temporary fix
that the user remembers to turn on when the announcement is made, and to turn
off at the end of the month.

------
NelsonMinar
The leap second has a history of breaking computers. Pretty much every Linux
server running Java broke in 2012, for example. 2009 saw a bunch of Linux
kernels crashing in logging code. 2016 was mostly better except for
Cloudflare: their systems had an assumption time never runs backwards.
[https://blog.cloudflare.com/how-and-why-the-leap-second-
affe...](https://blog.cloudflare.com/how-and-why-the-leap-second-affected-
cloudflare-dns/)

~~~
ggm
Not wanting to be a complete BSD bigot, I can't actually remember if this
broke in the {Free,Net,Open}BSD world as badly. The 2015 docs for FreeBSD
don't help (oh, for a time machine) but go to "you can test what we do" which
is good.

[https://www.freebsd.org/doc/en_US.ISO8859-1/articles/leap-
se...](https://www.freebsd.org/doc/en_US.ISO8859-1/articles/leap-
seconds/article.html)

~~~
ajross
Not to jump on the bigotry, but two of the three bugs mentioned in that
comment were in proprietary software (Java and RRDNS) that merely runs on
Linux. The hrtimer issue in 2012 was a real kernel bug though.

~~~
NelsonMinar
The 2012 bug was a bad interaction between Java and thread locking in the
Linux kernel. It affected MySQL as well. The 2009 bug was in the Linux kernel,
in the logging code. The 2016 bug I mentioned was in Cloudflare's proprietary
code and only had a big impact because so many websites use Cloudflare. There
are zillions of other smaller leap second related bugs, these are only three
of the most visible.

(btw, the word "bigotry" has a real meaning and this isn't it.)

------
drtillberg
Christ Church College at Oxford still makes a limited use of 'local time'
offset 5 minutes and 2 seconds from the time zone.

[https://greenwichmeantime.com/info/oxford/](https://greenwichmeantime.com/info/oxford/)

~~~
TomK32
Jolly good, the whole rail-road mania with their cum tempore timetables never
full-filled their fantasy of a unified time-zone for Old Blighty.

------
teddyh
This could very well have been called “ _Falsehoods programmers believe about
date and time calculations_ ”. It fits very well into the pattern of other
similarly titled lists which have been published in recent years.

~~~
severine
[https://infiniteundo.com/post/25326999628/falsehoods-
program...](https://infiniteundo.com/post/25326999628/falsehoods-programmers-
believe-about-time)

edit: which cites [https://infiniteundo.com/post/25326999628/falsehoods-
program...](https://infiniteundo.com/post/25326999628/falsehoods-programmers-
believe-about-time) (from HN's own patio11) as inspiration, as the original
"Falsehoods programmers believe about X".

~~~
mmt
I think you meant it cites [https://www.kalzumeus.com/2010/06/17/falsehoods-
programmers-...](https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-
believe-about-names/)

~~~
severine
You're right, thank you. I missed the edit window.

------
eldavido
This is actually a lot simpler than it looks. There are two concepts.

Calendars almost never have crazy holes in the middle of them. When you say
"I'm in Chicago", you pretty much can schedule an appointment at 1 or 2pm on
"Sunday" or "9/20" or "next Wednesday" and everybody knows when that will
happen. Leap years cause a little bit of trouble.

Where it gets tricky is when you have to interact with wall clock times, say,
calculating the number of hours until your calendar event happens, or looking
for all the events in a given range of wall clock dates. This is the world of
timestamps, offsets, and "the global timeline" that everyone in the world
experiences together.

Calendars also don't really care about daylight saving time.

If you keep these two separate and are specific about which you're dealing
with, 90% of this goes away. Separate calendar from arithmetic/wall clock
times. Not all will disappear, but a surprisingly large amount.

Source: working on [https://www.interval.org/](https://www.interval.org/) and
using the excellent NodaTime library. Thank you, Jon Skeet.

~~~
macintux
> Calendars almost never have crazy holes in the middle of them.

The comment right above yours at the moment talks about effectively that very
problem (in this case, an unforeseen date moving a calendar back a day).

[https://news.ycombinator.com/item?id=18036403](https://news.ycombinator.com/item?id=18036403)

------
yboris
The Problem with Time & Timezones - Computerphile
[https://www.youtube.com/watch?v=-5wpm-
gesOY](https://www.youtube.com/watch?v=-5wpm-gesOY)

A fantastic overview of the headaches you'd have if you wanted to code all
this.

------
netgusto
> Weeks start on Sunday in the United States, Monday in Europe, and a couple
> of places start on Saturday.

Wow. I live in Europe, and find it weird that people can consider the week to
start on Sunday.

I guess everything that may appear normal within a cultural frame of reference
can be off in another, even the most basic of things!

~~~
thaumasiotes
What is the relevance of saying that a week starts on a particular day? In the
most common usage, the "week" starts on Monday in the United States, and
concludes on Friday, to be followed by the "weekend". A calendar week of 7
days does start on Sunday, but who cares? If they changed how the calendars
were printed, life would be different in no way.

~~~
unwind
In parts of the world, weeks of the year are numbered, so that you can talk
about things happening "in week 43", and so on. For such a system, it's of
course quite important to agree on which day a new week begins. Also (again,
as a European) it feels very odd to not have the weekend (Saturday and Sunday)
be at the end of the week, but instead "straddle" between two weeks.

I found the original article a bit strange in it's partitioning of the world
into { US, Europe, some places }, I feel that is giving ... undue weight to
the US convention, but I haven't studied this to see if I'm right.

~~~
thaumasiotes
In the US, weeks are not numbered, and the way to refer to a week is e.g. "the
week of the 10th". (If you're talking about a different month, "the week of
September 10th".) You would usually name the Monday of the week because the
context is usually work-related.

I question whether "Thursday of week 37" is really that much clearer than
"Thursday, September 13".

~~~
unwind
Perhaps it's not, but it is a bit more compact and even more so in my native
language, Swedish. The names of months are longer: "September", which is the
same word in Swedish has four syllables while the word for week ("vecka") has
two.

And sometimes you really want to speak about the entire week without naming a
day ("we'll have the first boards week 40, smoke-test and bring-up during week
41, and then start proper development by week 42"), since it's times in the
future and you don't want to be too specific but still align work tasks with
weeks.

Also (re: a sibling comment) Google Calendar shows week numbers, or can be
configured to. For quickly finding out the week number, there's always
[https://vecka.nu](https://vecka.nu). :)

~~~
blattimwind
> Also (re: a sibling comment) Google Calendar shows week numbers, or can be
> configured to. For quickly finding out the week number, there's always
> [https://vecka.nu](https://vecka.nu). :)

KDE and i3 desktops can be configured for pretty much arbitrary date formats,
I always have the KW in there.

------
jchw
Many of these make the weird assumption that you want to support multiple
calendars. For better or worse, this is rarely the case.

~~~
xenadu02
I think that's a bit naive.

Properly supporting calendrical calculations serves two major purposes:

1\. Serve the billions of people who don't use the Gregorian calendar or who
live in areas that don't match your idea of time zones.

2\. Functions as a human form of "platform independence". Properly handling
dates/times quickly exposes places you've made silly assumptions or
accidentally broken things. This protects you from actual bugs and ensures you
avoid whatever the future version of the Y2K problem is. Such bugs are always
easier to fix when you have a smaller database and fewer users.*

* In general bugs and breaking changes _never_ get easier. Every day you delay increases the pain imposed on future you and users. Obviously there is a balance - a startup needs to worry about getting to "default alive" first and foremost - but don't delay too long and where it doesn't impose an inordinate cost do it right the first time.

~~~
nitwit005
> Serve the billions of people who don't use the Gregorian calendar or who
> live in areas that don't match your idea of time zones.

There isn't that much use of non-Gregorian calendars in software, even in
places that do make use of them. And if you do support them, it's another
source of bugs, as you have to deal with new Japanese era names and the like:
[https://blogs.msdn.microsoft.com/shawnste/2018/04/12/the-
jap...](https://blogs.msdn.microsoft.com/shawnste/2018/04/12/the-japanese-
calendars-y2k-moment/)

------
wolfv
I invented this very regular calendar while I was writing recurring-scheduling
software for a scheduling tool:

[https://calendars.wikia.com/wiki/6*6*10_regular_calendar](https://calendars.wikia.com/wiki/6*6*10_regular_calendar)

It was my fantasy escape from the crazy irregularities of the Gregorian
calendar.

~~~
pmontra
Can you imagine the transition to that calendar? People wanting their two days
off every five working days are one of the problems.

~~~
wolfv
It will never happen. The US can't even get on the metric system. The UN
couldn't even reform the calendar to have uniform quarters:
[https://en.wikipedia.org/wiki/World_Calendar](https://en.wikipedia.org/wiki/World_Calendar)
[http://strangeside.com/time-sabbath-on-tuesday-364-day-
year/](http://strangeside.com/time-sabbath-on-tuesday-364-day-year/)

------
cryogenic_soul
I think on of the best attempts to fix calendar system was done by George
Eastman (Kodak founder), who presented "International Fixed Calendar" created
by Moses Cotsworth to League of Nations in 1923. At that time League of
Nations was trying to redesign current calendar system and was accepting
different proposals.

Unfortunately they failed to come to consensus between different calendar
designs :(

[https://en.wikipedia.org/wiki/George_Eastman](https://en.wikipedia.org/wiki/George_Eastman)

[https://en.wikipedia.org/wiki/Moses_B._Cotsworth](https://en.wikipedia.org/wiki/Moses_B._Cotsworth)

[https://en.wikipedia.org/wiki/International_Fixed_Calendar](https://en.wikipedia.org/wiki/International_Fixed_Calendar)

[https://en.wikipedia.org/wiki/International_Fixed_Calendar_L...](https://en.wikipedia.org/wiki/International_Fixed_Calendar_League)

[https://gizmodo.com/how-the-quest-for-a-perfectly-
rational-c...](https://gizmodo.com/how-the-quest-for-a-perfectly-rational-
calendar-created-1697616634)

~~~
Asooka
That calendar's weeks start on Sunday and I would rather have hours vary by
length of daylight throughout the year than start weeks on bloody Sunday.

------
VeXocide
Here's my personal favorite, GMT +0h 19m 32.13s, which was used in the
Netherlands until July 1, 1937:
[https://en.wikipedia.org/wiki/UTC%2B00:20](https://en.wikipedia.org/wiki/UTC%2B00:20)

------
WalterBright
This really should be an operating system service, so all the applications get
it right. Instead, everybody rolls their own, with erratic results.

~~~
Spivak
Android:
[https://developer.android.com/reference/android/icu/util/Cal...](https://developer.android.com/reference/android/icu/util/Calendar)

Apple Everything:
[https://developer.apple.com/documentation/foundation/nscalen...](https://developer.apple.com/documentation/foundation/nscalendar)

CentOS:
[https://centos.pkgs.org/7/centos-x86_64/icu-50.1.2-15.el7.x8...](https://centos.pkgs.org/7/centos-x86_64/icu-50.1.2-15.el7.x86_64.rpm.html)

Windows: [https://docs.microsoft.com/en-
us/windows/desktop/intl/intern...](https://docs.microsoft.com/en-
us/windows/desktop/intl/international-components-for-unicode--icu-)

~~~
WalterBright
Only Microsoft's seems to be part of the operating system.

------
nneonneo
"False. The UNIX epoch is January 1, 1970 in UTC, but is Dec 31, 1969 in Los
Angeles."

This isn't _specific_ to Los Angeles, right? It's just referring to the fact
that anyone with a negative UTC offset would see an epoch date of Dec 31, 1969
in their local time (I hope).

~~~
pm215
One related wrinkle that can catch out UK people (who tend to conflate local
non-summer-time with UTC) is that the epoch is _not_ midnight 1 Jan 1970 in UK
time -- we were in the middle of a "UK time is GMT+1 all year round"
experiment in 1970...

------
SneakyMission
False. It’s the year 5779 in the Hebrew calendar. שנה טובה

~~~
abraham_lincoln
שנה טובה

------
kuwze
I’ve heard that Perl 5 has the best/most complete DateTime library. Is that
true?

~~~
petre
It cares about leap seconds so yes, it's quite accurate.

------
_ph_
Bonus problem: in my company, the business calendar (which is the first week
of the year, quarter ends) is sometimes shifted by one week with respect to
the ISO definitions for historic reasons.

I have implemented a large application which does a lot of time calculations,
and run onto most of the issues listed in the article, except that I didn't
use hewbrew calendars :).

------
akeck
For quick scripts, I do all my date math with seconds-since-the-epoch,
retrieved with "date", and then convert back at the end. The final date
benefits from the latest timezone package update, so mostly I do OK.

~~~
innocenat
This mostly work without problem for past time, but it can be wrong for future
time, since timezone/DST may change. When you want 2pm next Sunday, you want
2pm next Sunday _local time_ , not whatever 2pm next Sunday is supposed to be
as of now.

------
King-Aaron
I seem to remember Tom Scott doing a really good little video about this.

~~~
ilikehurdles
This one: [https://www.youtube.com/watch?v=-5wpm-
gesOY](https://www.youtube.com/watch?v=-5wpm-gesOY)

------
FrozenVoid
The whole problem results from people using the same time for user-display and
time calculations. Display time is user-facing feature that Should Not
Influence system time. If people used
[https://en.wikipedia.org/wiki/International_Atomic_Time](https://en.wikipedia.org/wiki/International_Atomic_Time)
for software none of the problems related to calendars will occurs. IAT has no
leap seconds or any calendar corrections at all.

------
throw7
Just learned google calendar uses the timezone your currently in by default
even if you set the location back to your home. When I got back from travel,
the notification was decidedly off. :)

~~~
Hnrobert42
Google’s “helpful” treatment of time zones decidely isn’t. I wish there was a
way to tell google calendar to ifnore timezones altogether.

E.g. I am in Vietnam. I make a dentist appointment for when I am back in the
US at 2 pm. I put the appointment on the calendar. I get to the US on the day
and find the appointment is at 1 am the day before. Worse still, is in the
opposite direction because I wont get the alarm until the event has passed by
11 hours.

Stop being clever google. If I put an event in my calendar for 2pm, just leave
it there. Yes, yes, I could hunt down the timezone menu item every time.
Better yet, I finally get around to transitioning out of that terrible
company’s services.

------
vortico
Is it true that Unix time is as simple as it seems? Is there exactly one
second between adjacent integers? Do all Unix time values occur only once
simultaneously around the world?

~~~
ushi
What you want is probably TAI [1], Unix Time has leap seconds.

[1]
[https://en.wikipedia.org/wiki/International_Atomic_Time](https://en.wikipedia.org/wiki/International_Atomic_Time)

~~~
Tor3
The one mistake with UNIX is that UTC is used. It should have been TAI, and
leap second adjustment should have been handled by the timezone package (but
at the time people weren't worried about leap seconds, so it's
understandable). As it is, the system clock has to _change_. This is as bad as
MSDOS time (and other systems which put localtime into the actual RTC). Using
UTC as the time reference, independent of local time, was nearly genius. With
TAI it would have been pure genious. No, wait, using an epoch time of the Big
Bang, and step size Planck time, now that would have been pure genious. It
doesn't take as many bits as you may think..

~~~
zokier
Frankly I'm bit confused why civil time in general is based on UTC instead of
TAI. Except for astronomy, who does benefit from observing leap seconds?

~~~
bloak
Civil timekeeping is based on UTC because we want clocks and calendars to
remain synchronised with the sun. It's not just astronomers who care about
whether the sun is above the horizon. If you think about it, the solar day is
the one unit of time that almost everybody cares about and pays attention to.
If you screw up the day, you also screw up the week and anything else that is
based on counting days. Why would you want to do that?

~~~
repolfx
But offset of UTC for TAI is like 37 seconds or something poxy like that.
Nobody cares about this, the sun moves too slowly for that to make any
difference.

There's been talk of setting UTC=TAI for quite a long time and I think it'd
make sense. It'd take so long for TAI to drift from the actual rising and
setting of the sun that we'd probably all have standardised on Swatch Beats by
then anyway.

~~~
bloak
Yes, the difference is 37 seconds now, but it's growing quadratically. It's
quite possible that we'll change the way we express times and dates, but it's
almost certain that we'll want them to stay in phase with the sun, and we'll
probably want to stick with the SI second and with something like TAI. My
guess is we'll continue to want a simple relationship between TAI (or its
successor) and the civil clock time, something like the current relationship
according to which they are a whole number of seconds apart. That implies that
we'll need something like leap seconds (or leap minutes perhaps). There
doesn't seem to be a reasonable alternative.

~~~
sla29970
In 1950 astronomers pointed out that there would have to be two kinds of time,
one to agree with calendar days and one to be as uniform as possible.
Arguments over subsequent decades inexplicably decided that there could only
be one kind of time specified by international agreements, and we ended up
with a choice of two out of three characteristics in what we now call UTC.
[https://www.ucolick.org/~sla/leapsecs/picktwo.html](https://www.ucolick.org/~sla/leapsecs/picktwo.html)

~~~
zokier
You website is a true hidden gold nugget, thanks for putting in the time to
write all that up.

As an expert (as far as anyone around here is), what would your pick be for
common civil time? Personally I feel like "precise time and simplicity" is
almost obvious choice, but apparently it is not quite that clear cut.

~~~
bloak
"Simplicity" is rather subjective, even if you answer the question: simple for
who?

Civil time has to stay in phase with the sun. As I see it, that's not
negotiable. Inserting leap seconds, so that the nanosecond field of UTC
remains the same as the nanosecond field of TAI, and the jumps that occur are
negligible for ordinary people, seems to me overall the simplest solution,
though I can see that UTC-SLS would be simpler for some people in some
situations, and switching to leap minutes or leap hours would be simpler for
people living _now_ , who could then just ignore the problem. (Pollution and
global warming and lots of other things can be treated in the same way, of
course. Perhaps some of these things really will be easier to solve in the
future, but I'd rather not rely on it.)

~~~
zokier
> "Simplicity" is rather subjective, even if you answer the question: simple
> for who?

I used simplicity in the meaning provided by link in parent comment refering
to three desirable properties of time systems: "Every "day" has 86400
"seconds" (60 _60_ 24)."

> Civil time has to stay in phase with the sun. As I see it, that's not
> negotiable.

I don't see why that needs to be the case on a seconds level.

> switching to leap minutes or leap hours would be simpler for people living
> now, who could then just ignore the problem. (Pollution and global warming
> and lots of other things can be treated in the same way, of course. Perhaps
> some of these things really will be easier to solve in the future, but I'd
> rather not rely on it.)

Considering that need for leap hour would appear in over 500 years, I feel
like trying predict the situation then is really borderline overarrogant.

Also leap hour would be basically a timezone shift, and I bet we will be doing
timezone changes anyways in the _next 500 years_

~~~
bloak
Not at all. Just because it involves an "hour", rather than a "second",
doesn't mean that it resembles a "timezone shift". It's totally different.

With a timezone shift, all that happens is that "09:00:00 +0900" is the same
as "10:00:00 +1000". We can cope with that. But if you make UTC jump back an
hour, then we have "09:59:59 +1000" followed by "09:00:00 +1000", and then the
whole previous hour happens again. The internal timestamps in computer systems
(typically expressed as a number of seconds since some epoch) repeat
themselves for an hour. Causality is violated. Most computers stop working.
You would probably have to switch them off beforehand to prevent data loss and
even longer interruptions to service. You could shut down all the servers and
desktop machines, stop all public transport and so on, but you can't just turn
off the computers in embedded systems and satellites and so on...

So let's not try to arrogantly predict the situation in 500 years. Let's carry
on with the established system of leap seconds, at least until someone comes
up with a sensible alternative. Then there won't be a "situation" in (less
than) 500 years.

------
Balgair
As the ephemeral Tom Scott also demonstrates [0], even IF you account for all
the listed factors (and many more) you are STILL sometimes out of sync, just
due to the nature of the power grid _itself_.

As Albert said: Time is what clock measure. The more you dig into it, the more
you realize how true that is!

[0] [https://www.youtube.com/watch?v=bij-
JjzCa7o](https://www.youtube.com/watch?v=bij-JjzCa7o)

------
acd
Wisdom and experience from senior hacker developer "Oh you are working with
time and dates that is going to get "complicated""

Lets propose a new time format we could count the number of exoseconds since
the beginning of the universe. Then convert that number to whatever native
time format we want. Store that as a number and use that for conversion. Age
of universe 4.415×10^17 seconds, 4.415×10^26 exoseconds

~~~
flukus
Not universal enough, areas near a black hole have experienced less time, the
CMB has experience 0 exoseconds, even earth and space will slowly diverge.
This will just make a lot of future programmer cyborgs very unhappy.

------
peter303
Choose a non-Earth-centric time standard. People speculate how a space-faring
society would be able to synchronize time and location under relativistic
physics. The answer is an intergalactic GPS using far away qusar locations and
frequencies. The Voyager probes located Earth for a futrue viewer using a
quasar GPS.

~~~
justinjlynn
still not stable over long time periods unless you account for stellar drift
(which gets more and more uncertain over time)

------
zipwitch
From the list: _All the important years are four digits long_

This left out the Long Now Foundation's advocacy for five-digit years to deal
premptively with the Y10K bug. And, less tongue-in-cheek, to promote a view of
time that is not conventional in this day and age.

~~~
lxmorj
[https://www.youtube.com/watch?v=czgOWmtGVGs](https://www.youtube.com/watch?v=czgOWmtGVGs)

------
Zaheer
Reminds me of another great post on the topic by Zach Holman:
[https://zachholman.com/talk/utc-is-enough-for-everyone-
right](https://zachholman.com/talk/utc-is-enough-for-everyone-right)

------
partycoder
> Weeks start on Sunday

> False. Weeks start on Sunday in the United States, Monday in Europe, and a
> couple of places start on Saturday.

In some countries weeks start on Mondays.

> All the important years are four digits long

> False. It’s the year Heisei 30 in the Japanese calendar.

Or 13.0.5.15.0 in the Maya calendar.

------
StreamBright
The only question I got is: why we as humans cannot fix this by having a
proper calendar system that actually reflects the world and does not have
these flaws?

~~~
pmontra
The world is irregular (Earth's rotation and revolution durations vary) but we
want regularity in our calendars and clocks. That's the source of the problem.

------
hesk
What surprised me the most on that list was the the Unix epoch is December 31,
1969 in Los Angeles.

~~~
rossy
Don't let that answer confuse you. It seems to be phrased in an intentionally
confusing way, but it's really only talking about time zones. At midnight
1970-01-01 UTC, Los Angeles, North America, and roughly half of the world
still had their calendars on the previous day, because they have a negative
time zone offset (Los Angeles was UTC-8:00).

------
joshu
Yours in calendrical heresy, JS

~~~
MrMorden
Just as well this article doesn't contain a technique for locally making P=NP.
I've never trusted Vidona, and I never will.

------
shimon
After I read to the end, I half expected it to load more calendar fallacies.

------
peter303
A proper programmed petaflop computer should be able to handle this.

------
draw_down
I really dislike the tone these sort of things tend to take, which is “here’s
some stuff you think but you’re wrong about.” The reason people get stuff like
this wrong (and names, and addresses, and and and) is because it’s really hard
to get right. And it’s added difficulty on top of writing code which is
already pretty challenging.

~~~
Semiapies
Especially when it's all stuff that's already been covered in very similar
essays.

Actually introducing good libraries and methods for handling these issues
properly would be much more useful than a smug collection of fallacies and a
tacked-on link to ICU at the end.

~~~
kenferry
I don’t understand this objection.. the method to handle these issues is to
use ICU / NSCalendar.

~~~
repolfx
Or a runtime equivalent, e.g. the java.time package gets this stuff right.

------
Lapsa
programming in a nutshell

------
Theodores
Imagine we did not have names for months and days. Would you call the tenth
month October or December? It does not make sense. Then, the other months at
the start of the calendar, would you name them after phases of a military
campaign of preparation for war, conquering, looting and pillaging? Would that
be deemed politically correct?

On the weekday names we are not doing any better. Tuesday - named after the
god of war? Doesn't make sense to me.

As for the lengths of the months, imagine if you were trying to make the case
for the different lengths of months and you were trying to get buy in from
your friends in accounts. Surely they would want equal amounts of days in each
quarter? Imagine trying to persuade them that different lengths were better,
what plausible possible reason could there be?

We learn the names of days and months by rote at a very young age. We get
encultured into accepting the status quo and never questioning little details
- nobody asks at school why 'Dec'-ember is month twelve.

~~~
gruez
simple: call them by their ordinal/cardinal names. that's what east asian
calendars do. october is "month ten"

[https://en.wikipedia.org/wiki/Japanese_calendar#Months](https://en.wikipedia.org/wiki/Japanese_calendar#Months)

[https://en.wikipedia.org/wiki/Names_of_the_days_of_the_week#...](https://en.wikipedia.org/wiki/Names_of_the_days_of_the_week#East_Asian_tradition)

~~~
freeone3000
That's what we did in latin! October is month 8! And then some dude messed it
up.

~~~
Tor3
Yeah, the dude changed the definition of where the new year starts, moving it
back two months. It's still arbitrary, it should have been at the (slightly
fuzzy) winter solstice..

