Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Excel incorrectly assumes that the year 1900 is a leap year

learn.microsoft.com

Post reply on HN
Print view View original

31–36 of 36 posts

Re: Excel incorrectly assumes that the year 1900 is a leap year

#31

Post by rkomorn »

sam_lowry_ wrote: post #30
shakna wrote: post #16

Earlier quoted context omitted.

Numa did try to name and consolidate the winter months, but it wasn't very popular. The months were for productive seasons, winter for everything else.

Also French revolutionaries ;-)

I'm French and occasionally like to (re)read about the revolution period and every time I come to the calendar stuff I can't help but think "Really? This was stuff we wanted to spend time on?"

Re: Excel incorrectly assumes that the year 1900 is a leap year

#32

Post by rsynnott »

teraflop wrote: post #11
emmelaich wrote: post #9

Earlier quoted context omitted.

You may know this but originally they were 'correct' because the start of the year was March.

Which wouldn't be that weird, except that the earliest Roman calendar started in March and ended in December, having only 10 months! The Romans were of course well aware that this left a gap of about two months between the end of one year in December, and the beginning of the next year in March. But they just didn't bother counting this period as part of the calendar year. Presumably because there was no agricultural…

AIUI, there is some confusion over whether this is actually the case. The pre-Julian calendar had 12 months, plus an optional intercalated month (they were aware that their ‘year’ had the wrong number of days, and periodically shoved in some extra time to patch it up). The 10 month calendar, if it existed, would have been very early and there’s not much hard evidence that it was actually used. Numa Pompilius, who was allegedly responsible, is a mythical figure and probably not an actual historical king.

Re: Excel incorrectly assumes that the year 1900 is a leap year

#34

Post by jagged-chisel »

jwrallie wrote: post #26

I was developing an interface to read a .xslx file to import a table within a Qt/C++ program, and this detailed showed up in my conversions to Unix time. It turns out Claude was amazing and brought up this issue as soon as Excel was mentioned, but terrible at actually fixing up the calculations. I'd prefer using a .csv with dates already converted to Unix time, but no luck convincing the other people involved.

You should export datetimes as human-readable strings. Helps debugging. (And does nothing to guarantee they’re correct, just like every other attempt at a solution.)

Re: Excel incorrectly assumes that the year 1900 is a leap year

#35

Post by zvr »

etothepii wrote: post #4
darknavi wrote: post #3

> Applies to: Microsoft Excel for Mac 2011, Excel for Microsoft 365 for Mac, Microsoft Office Excel 2003, Microsoft Office Excel 2007, Excel 2010, Excel 2013, Excel 2016

This will never stop as it would require either the reference date to be changed or fir all dates in all saved spreadsheets to be off by one.

IIRC, it will never stop because now it has been "standardized". The OOXML specification explicitly mentions that the conversions of dates and their attributes (like whether a year is a leap one) has to follow the Excel implementation.

Re: Excel incorrectly assumes that the year 1900 is a leap year

#36

Post by gerdesj »

caminante wrote: post #15
gerdesj wrote: post #6

Earlier quoted context omitted.

To be fair, that's nowhere near as daft as september, october, november, december. Latin for seven, eight, nine, and ten is: septem, octem, novem, decem. Those are the nineth, 10th, 11th and 12th months. Edit: Whoops, correct eng -> latin nums

No? How is it octem and not octo? Does the flat bar accent do something? >The Latin word for "eight" is octō. [0] [0] asked google

40 years since I studied Latin and a few glasses of wine and it was late ...
Post reply on HN