Was the year before that 0 CE or 1 BCE?
This is a meta-programming question, relating to the religious wars over the first number in a list. Should it be 0 or 1?
Some points to consider:
What would Richard Stallman say? I read an article by him recently where he got upset that the OLPC is offering Windows. He listed the reasons this is bad. The list was numbered, starting with 0.
How would they have handled the year 10 problem (Y1), when suddenly computers had to double the number of bits stored per year?
How would Joel have handled this, considering that when he proposed a new version of dates for the excel macro language, he took into account that the date IDs would be wrong for dates in January and Febrauary, 1900? (See here: My First BillG Review)
Edit: The Wikipedia entry quoted by #Svelil below says there was no year 0 CE, just for the record. We went straight from 1 BCE to 1 CE.
Should it be 0 or 1?
Wikipedia has a nice article about this: Year Zero
As starting list-counts at zero is pretty common in programming, I would personally adhere to that standard.
How would they have handled the year 10 problem?
Use your feet :-) (Hey, it actually doubles your ability to count)
Was the year before that 0 CE or 1 BCE?
1 BCE, though it wasn't called so before that time.
How would they have handled the year 10 problem (Y1), when suddenly computers had to double the number of bits stored per year?
Right, they ran out of fingers.
In fact, Y2k was not the first date problem.
When Caesar died and left no records on how to use Julian calendar, Octavian applied leap year once in three years, not four. They noticed that in 9 BC and there were no leap years until 8 AD to correct the difference.
As the MAD Book About World History said:
1 BCE. The world's greatest historians can't agree what to call the next year.
Related
Instant.FromUnixTimeSeconds(-100100000000).ToDateTimeUtc1
Once the date gets too ancient this doesn't work anymore, for example, BC dates.
Is there any easy way to convert NodaTime instant values to years months days, that works for the entire range of supported Instant values (aka 27000 BCE to 31000 CE) ?
I don't mind what data type, I am just looking to easily extract the regular time periods from the Instant values.
It's been a year or more since I've used Nodatime, but [this page in the user guide][1] says
Additionally, all calendars are restricted to four digit formats, even
in year-of-era representations, which avoids ever having to parse
5-digit years. This leads to a Gregorian calendar from 9999 BCE to
9999 CE inclusive, or -9998 to 9999 in "absolute" years.
You're question could be read to mean you didn't think BC dates worked at all. When you get more than a few thousand years from the present, strange things start to happen, such as the changing rotation rate of the Earth means there are different kinds of days; those that would be counted from sunrises vs. the kind of time used in radioactive decay, or calculation of planetary positions. It might be helpful if you mentioned your application.
[1]: https://nodatime.org/3.1.x/userguide/range
I am trying to understand how the difference between DATEDIF(date1,date2,"d") and DATEDIF(date1,date2,"yd") in excel. It is very confusing when trying to deal with leap year dates.
for example
=DATEDIF("2/29/2020","3/1/2021","yd") gives 0.
but when I try to give
=DATEDIF("2/29/2020","3/1/2021","d") gives 1.
and one more thing is
=DATEDIF("2/1/2020","3/1/2021","yd") gives 29 and
=DATEDIF("2/1/2019","3/1/2021","yd") gives 28.
Some of the articles claim that year of start date is used for calculations so with that logic DATEDIF("2/29/2020","3/1/2021","yd") should give 1 instead of zero. Can someone explain how the calculations are being done and what year is being considered for the calculations?
From the docs you can see what is the difference.
To be explicit, the YD variant isn't taking year into account, thus showing different results in the case of leap year.
I'm using the new STOCKHISTORY function in Excel and I'd like to always display the past 17 trading days from the point I indicate. The problem is with long weekends and holidays this alters the amount of business between two dates. I'm not sure if this will be a difficult question because I think the solution is not dependent on the fact that I'm using the STOCKHISTORY function. I have attached a photo with a simple explanation. On the left the formula for STOCKHISTORY is =STOCKHISTORY(E2,C4-C6,C4,0,1,0,2). This displays 17 business days because 22 is the magic number. On the right though if I query July 22nd with 22 day difference I only get 16 days. This is further wrong on many other dates.
I am open to having a separate reference on another sheet that has dates/formulas. I tried this but couldn't figure out a formula to pull down. Photo B displays an example of the correct number of dates that would show 17 trading days. I am also open to displaying more than 17 trading days as in the future I will need to alter the amount of trading days needed (I might need to display 15 days or 20 days).
In my head I feel like the answer has something to do with the NETWORKDAYS function and/or I should make a list of all the trading days in a year and then make a formula taking the current day and taking away a specific day. Or I could be totally wrong and the answer is obvious.
So I figured out an answer after reading some documentation. There is most likely better answers but it solves the problem enough.
So I created a list of all trading days (business days) as you can see in column O. Then in Column L a list of nearby holidays (Only needed a few exceptions). Then using the formula =(O35)-(WORKDAY(O36,-17,$L$35:$L$36)) I get the right solution which I verified in my example photo posted earlier. You could theoretically get a different number when doing your own calculations (i.e the answer 24 and 23 are both correct).
UPDATE I tried to upload pictures, but I got the message that I couldn't upload pictures but I got links instead. Let me know if this works...
Thanks for taking a second to look through this. This is my first post so I am trying to make sure that I make the question (and hopefully, the solution) relevant to more than just me.
I work in a repair/manufacturing planning position and have to identify the bottlenecks in my various processes. I have one type of asset that has multiple flavors. For example, if I worked on Honda Accords, I would have to distinguish between a 1986 Accord LX from a 1996 Accord EX-L.
Based on the induction schedule of my assets and how long they take in different parts of my processes, these bottlenecks can be manifest in several different ways: a lack of facility space, a lack of a certain type of manpower, or a lack of support equipment just to name a few. Now, I have dates for incoming assets for the next two years, and I have the durations for the different parts of my processes that each type of asset will. More simply: an Accord from 1986 takes 3 weeks to inspect (Gate 1), 4 weeks to repair (Gate 2) and 5 weeks to put back together and test (Gate 3); whereas an Accord from 1996 takes 3 weeks to inspect(Gate 1) 2 weeks to repair (Gate 2) and 3 weeks to put back together and test (Gate 3).
I have already been able to take the incoming dates an lay them out on our fiscal year (vs. the calendar year) using =weeknum(). I then used an =IF() to place an "x" on the corresponding week.
What I am looking to do is place a series of colored cells (corresponding to the weeks of the gates) that starts in the cell with the "x" and extends to the cells to the right the number of cells corresponding to the number of weeks. For example, if I have a 1986 Accord start in week 3, I would like the 3 cells to the right to be blue, followed by 4 green cells, and finally 5 yellow cells. I am essentially trying to graphically represent the times that the assets will be within my facilities and where my bottlenecks are. If I only have 5 locations for Gate 1 and my waterfall shows I have times where I need 8 spaces, I need to let the boss know.
I didn't see a way to upload the files I am working from, so if someone will let me know, I'll post up what I have so far...
Again, thank you for looking.
The data as I initially receive it and format it: Initial Information
The finished waterfall product I am looking to make: Final Waterfall
When I use the formula datevalue("01/01/1900") I get 1 and formatted as a date it shows as 01/01/1900
When I use VBA
.Range("A1").Value = DateValue("01/01/1900")
it shows up as "02/01/1900" in the cell
How is this possible?
If i use for example
.Range("A1").Value = DateValue("01/01/1901")
it works fine!
Head Melted!!!
Microsoft state that - "Using the default date system in Microsoft Excel for Windows, the date_text argument must represent a date between January 1, 1900 and December 31, 9999"
In short, Excel's DateTime epoch is not the same as VBA's DateTime epoch. Although, they are the same once you get past February 28th, 1900.
From Joel Spolksy's blog:
In most modern programming environments, dates are stored as real
numbers. The integer part of the number is the number of days since
some agreed-upon date in the past, called the epoch. In Excel, today's
date, June 16, 2006, is stored as 38884, counting days where January
1st, 1900 is 1.
I started working through the various date and time functions in Basic
and the date and time functions in Excel, trying things out, when I
noticed something strange in the Visual Basic documentation: Basic
uses December 31, 1899 as the epoch instead of January 1, 1900, but
for some reason, today's date was the same in Excel as it was in
Basic.
Huh?
I went to find an Excel developer who was old enough to remember why.
Ed Fries seemed to know the answer.
"Oh," he told me. "Check out February 28th, 1900."
"It's 59," I said.
"Now try March 1st."
"It's 61!"
"What happened to 60?" Ed asked.
"February 29th. 1900 was a leap year! It's divisible by 4!"
"Good guess, but no cigar," Ed said, and left me wondering for a
while.
Oops. I did some research. Years that are divisible by 100 are not
leap years, unless they're also divisible by 400.
1900 wasn't a leap year.
"It's a bug in Excel!" I exclaimed.
"Well, not really," said Ed. "We had to do it that way because we need
to be able to import Lotus 123 worksheets."
"So, it's a bug in Lotus 123?"
"Yeah, but probably an intentional one. Lotus had to fit in 640K.
That's not a lot of memory. If you ignore 1900, you can figure out if
a given year is a leap year just by looking to see if the rightmost
two bits are zero. That's really fast and easy. The Lotus guys
probably figured it didn't matter to be wrong for those two months way
in the past. It looks like the Basic guys wanted to be anal about
those two months, so they moved the epoch one day back."
"Aargh!" I said, and went off to study why there was a checkbox in the
options dialog called 1904 Date System.
The information below was taken from this Super User answer.
As described in Microsoft KB 214058:
Days of the week before March 1, 1900 are incorrect in Excel
MORE INFORMATION
When the date system in Microsoft Excel was originally created, it was designed to be fully compatible with date systems used by other spreadsheet programs.
However, in this date system, the year 1900 is incorrectly interpreted as a leap year. Because there is no February 29 ("leap day") in the year 1900, the day of the week for any date before March 1, 1900 (the day after the "leap day"), is not computed correctly.
The "other spreadsheet programs" refer to Lotus 1-2-3, which was quite popular back then, and incorrectly assumed that year 1900 was a leap year. This is explained in even more detail in KB 214326:
Excel 2000 incorrectly assumes that the year 1900 is a leap year
MORE INFORMATION
When Lotus 1-2-3 was first released, the program assumed that the year 1900 was a leap year, even though it actually was not a leap year. This made it easier for the program to handle leap years and caused no harm to almost all date calculations in Lotus 1-2-3.
When Microsoft Multiplan and Microsoft Excel were released, they also assumed that 1900 was a leap year. This assumption allowed Microsoft Multiplan and Microsoft Excel to use the same serial date system used by Lotus 1-2-3 and provide greater compatibility with Lotus 1-2-3. Treating 1900 as a leap year also made it easier for users to move worksheets from one program to the other.
Although it is technically possible to correct this behavior so that current versions of Microsoft Excel do not assume that 1900 is a leap year, the disadvantages of doing so outweigh the advantages.
If this behavior were to be corrected, many problems would arise, including the following:
Almost all dates in current Microsoft Excel worksheets and other documents would be decreased by one day. Correcting this shift would take considerable time and effort, especially in formulas that use dates.
Some functions, such as the WEEKDAY function, would return different values; this might cause formulas in worksheets to work incorrectly.
Correcting this behavior would break serial date compatibility between Microsoft Excel and other programs that use dates.
If the behavior remains uncorrected, only one problem occurs:
The WEEKDAY function returns incorrect values for dates before March 1, 1900. Because most users do not use dates before March 1, 1900, this problem is rare.