Live data from Hacker News

A glitch in February of the year 0

28times.com

21–26 of 26 posts

Re: A glitch in February of the year 0

#21

Earlier quoted context omitted.

If there was a year 0, we would still be in the 21st century. It would just have started 1 year earlier, in 2000 instead of 2001: 0 – 99: 1st century 100 – 199: 2nd century ... 1900 – 1999: 20th century 2000 – 2999: 21st century Although I think centuries are usually treated as starting in years ending in 0 anyway, in casual settings. Most people were certainly happy to celebrate "the new millennium" at the start of…

> 2000 - 2999: 21st century You have the right idea, but you made the 21st century a millennium

Argh! I knew I'd make a stupid mistake like that. (Now too late to edit.)

Re: A glitch in February of the year 0

#22

Their implementation must surely be wrong anyway (caveat: I've not looked at the code) if they're worrying about leap years for year 0 / 1BC. Leap years didn't exist prior to AD 45, and then leap centuries were added from 1600 onwards (and 11 days missed out in 1582 to compensate for the leap years that were added on centuries that shouldn't have had the extra day added). If the astronomical calendar is the same as G…

Yeah, it seems strange to get this "working", because fundamentally there is no correct answer. Our calendar isn't well defined in any consistent fashion back to then.

Re: A glitch in February of the year 0

#23

Earlier quoted context omitted.

00:00:00, there is no time such as 24:00:00. There could be 23:59:59, then 00:00:00.

And 12:00:00 is noon, which no one ever wanted for a calendar day change.

12:00am midnight on a 12 hour clock.

Re: A glitch in February of the year 0

#24
post #14

Earlier quoted context omitted.

00:00:00? Surely 12:00:00 or 24:00:00?

00:00:00, there is no time such as 24:00:00. There could be 23:59:59, then 00:00:00.

I've always seen it formatted as 24:00 to clarify it's 24 hour format and to mirror 12 hour time.

Re: A glitch in February of the year 0

#26

Their implementation must surely be wrong anyway (caveat: I've not looked at the code) if they're worrying about leap years for year 0 / 1BC. Leap years didn't exist prior to AD 45, and then leap centuries were added from 1600 onwards (and 11 days missed out in 1582 to compensate for the leap years that were added on centuries that shouldn't have had the extra day added). If the astronomical calendar is the same as G…

Author here.

Our aim isn’t to try and line up with the calendar that was in use at the time, 2026 years ago.

Instead, the aim (for 28times) is to implement the rules of the proleptic Gregorian calendar[0] correctly. The bug was that those rules weren’t followed for some rare values.

But to address your comment properly, I think I should justify why on Earth someone would want to use the proleptic Gregorian calendar for year 0 and before. In short, because it’s a useful fiction.

The biggest reason is interoperability: a lot of software follows proleptic Gregorian rules, aligning around ISO 8601. Probably a clear majority of date/time software. We want to line up with all that existing software that assigns a specific meaning to a string like "0000-02-01". That’s the first of February in the proleptic Gregorian calendar, even though it was a different date in the ancient Romans’ calendar.

The other reason is to keep it simple: since most people use the Gregorian calendar in present times, it’s simplest (for us as implementors, but also for users) to extend its rules into the distant past and distant future. The alternative for be to have multiple sets of rules, e.g. Julian and Gregorian calendar. (You might say it would be even simpler to just not allow timestamps before 1582. But there are use cases, e.g. in astronomy or history, where people want to work with timestamps before 1582, and even before 1 AD.)

[0] https://en.wikipedia.org/wiki/Proleptic_Gregorian_calendar

Post reply on HN