This structure is a 64-bit value representing the number
of 100-nanosecond intervals since January 1, 1601.
Reference: http://msdn.microsoft.com/en-us/library/aa915351
Why it is set "since 1601"? Why not unix time 1970 or even 2000?
What can I do with the compatibility of so distant in time dates?
Answering to myself.
The ANSI Date defines January 1, 1601 as day 1, and is used as the origin of COBOL integer dates. This epoch is the beginning of the previous 400-year cycle of leap years in the Gregorian calendar, which ended with the year 2000.
as you can find in wikipedia under Julian_day entry.
Further:
Why is the Win32 epoch January 1, 1601
Because 1/1/1601 was the start of the epoch.
Take it from Raymond Chen:
Why is the Win32 epoch January 1, 1601?🕗
The FILETIME structure records time in the form of 100-nanosecond intervals since January 1, 1601. Why was that date chosen?
The Gregorian calendar operates on a 400-year cycle, and 1601 is the first year of the cycle that was active at the time Windows NT was being designed. In other words, it was chosen to make the math come out nicely.
I actually have the email from Dave Cutler confirming this.
Bonus Chatter
RFC4122 UUIDs also measure 100ns ticks, but they start at 10/15/1582 (as opposed to FILETIME's 1/1/1601:
Date Ticks Uuid Epoch ticks
---------------------- ------------------ ------------------
1582-10-15 -5748192000000000 0 Start of uuid epoch
1601-01-01 0 0x00146BF33E42C000 Start of Windows epoch
1899-12-30 0x014F35A9A90CC000 0x0163A19CE74F8000 Lotus 123/Excel/Access/COM zero date
1900-01-01 0x014F373BFDE04000 0x0163A32F3C230000 SQL Server zero date
1970-01-01 0x019DB1DED53E8000 0x01B21DD213814000 Unix epoch timestamp
2000-01-01 0x01BF53EB256D4000 0x01D3BFDE63B00000
2010-01-01 0x01CA8A755C6E0000 0x01DEF6689AB0C000
2020-01-01 0x01D5C03669050000 0x01EA2C29A747C000
//FILETIME eras
1972-01-21 11:43:51 PM 0x01A0000000000000 0x01B46BF33E42C000 Start of 0x01A era
1986-04-30 11:43:13 AM 0x01B0000000000000 0x01C46BF33E42C000 Start of 0x01B era
2000-08-06 11:42:36 PM 0x01C0000000000000 0x01D46BF33E42C000 Start of 0x01C era
2014-11-14 11:41:59 AM 0x01D0000000000000 0x01E46BF33E42C000 Start of 0x01D era
2029-02-20 11:41:22 PM 0x01E0000000000000 0x01F46BF33E42C000 Start of 0x01E era
2043-05-31 11:40:44 AM 0x01F0000000000000 0x02046BF33E42C000 Start of 0x01F era
//UUID eras
1968-02-11 11:43:13 AM 0x019B940CC1BD4000 0x01B0000000000000 Start of uuid 0x01B era
1982-05-20 11:42:36 PM 0x01AB940CC1BD4000 0x01C0000000000000 Start of uuid 0x01C era
1996-08-27 11:41:59 AM 0x01BB940CC1BD4000 0x01D0000000000000 Start of uuid 0x01D era
2010-12-04 11:41:22 PM 0x01CB940CC1BD4000 0x01E0000000000000 Start of uuid 0x01E era
2025-03-13 11:40:44 AM 0x01DB940CC1BD4000 0x01F0000000000000 Start of uuid 0x01F era
Bonus Chatter
Excel uses a zero date of 12/30/1899 in order to be bug-for-bug compatible with Lotus 1-2-3. Which is also why Excel considers February 1900 to be a leap year (because the Lotus 1-2-3 guys thought it was). Which is why it's also impossible to represent dates before March 1, 1900 in Excel.
Well, 1 January 1601 was the first day of the 17th Century. And pendulum clocks were invented in the 17th century, allowing time to be measured to 1 second accuracy1. So (in theory) there might be references in extant literature from that period to timepoints measured with that accuracy.
But in reality the choice is arbitrary. There has to be an "epoch", and provided
the epoch is far enough back that "negative time" values are rare, and
the wrap-around time is far enough in the future to be a few generations away,
any choice will do.
But hey, if it worries you that much, send a letter to Steve Balmer2.
I'm inclined to believe Ian Boyd's answer, given the claimed source. And the reason therein is that it makes the math easier (for Gregorian leap year calculation). However, given how tiny that simplification is, and how weak the reasoning behind it, the choice is (IMO) essentially arbitrary. (Not that I'm saying it is wrong ...)
1 - OK ... probably not that accurate.
2 - Or Satya Nadella.
Its a pragmatic choice.
The modern western calendar was not consistent until 1752 when Britain (and its colonies) adopted the Gregorian calendar, which had been adopted in most of catholic Europe since 1582.
This is the modern calendar with leap years etc. to keep the 1st of January aligned with the winter solstice.
So why not start from 1st January 1752? Because the basic leap year rule "Its a leap year if the two digit year is divisible by four except if the four digit century is also divisible by four") established a 400 year cycle. The first full cycle starting on 1st January 1601, (at least in Rome).
The leap year and date calculations are painful enough without starting midway through a four hundred year cycle so 1600 is a pretty good start as long as you remeber that any dates before 1752 need to be qualified by a geographic location, as British dates were 10 days out of sync. with Roman dates by this time.
As has already been mentioned I think the popular answer is because the Gregorian calendar operates on a 400-year cycle, and 1601 is the first year of the cycle that was active at the time Windows NT was being designed.
January 1, 1601 is origin of COBOL integer dates.
It is also day 1 by ANSI date format.
And if you speculate further according to ISO8601 which is the format in which it is in, prior to 1583 time was based on the proleptic Gregorian calendar which has 366 days per year. Perhaps they just rounded up to the next century.
Related
I would like a spreadsheet row to contain the date of today, but only on every other Thursday, changing at 9:30 am.
To give you an example:
Next thursday the 21.07.16 it shell contain "21.07.16".
Until in exactly 14 days on thursday the 4.08.16 it shell contain this date and than change to 4.08.16.
Also I would like this change to happen at 9:30 am.
I can not think of a way how to do this. Can you point me into a direction?
One has to set a starting datetime somewhere in the past, such as July 7, 2016, at 9:30am.
Then find the difference between the current and the starting datetime. Truncate this difference down to a multiple of 14, and add this value to the starting datetime.
The datetimes are represented in Sheets numerically as the number of days since December 30, 1899. In this system, 2016-07-07 9:30 is about 42558.4 So the formula would be
=42558.4 + 14*floor((now()-42558.4)/14)
The output should be formatted as a date.
A less cryptic version is
=value("2016-07-07 09:30") + 14*floor((now() - value("2016-07-07 09:30"))/14)
(value follows the local convention for parsing dates, but I hope the format I used will be understood universally.)
As per ISO 8601, the first week is the week having at least 4 days and week start with Monday. For countries where the week starts with another day, like Sunday, how is the first week defined ?
Weeks can be defined in all sorts of ways.
The ISO 8601 standard way (starts on Monday, week # 1 has first Thursday of year) is sensible and practical, and increasingly common. In Java and its java.time framework (see Tutorial), the standard defined behavior is encapsulated in the IsoFields class. See my Answer to another Question for examples.
The non-standard approaches vary widely. Be very clear in determining such definitions with the stakeholders in your project. Document the definitions in your code base as well.
Often a company uses their own defined fiscal year for other business purposes, while some companies use the fiscal year only for bookkeeping and another calendar system for operations. Often the fiscal year is defined by its last day being a certain day-of-week such as the Friday closest to 31 December. So a year may have 52 or 53 weeks.
Sometimes week number 1 is the week containing January 1. Some people include the prior days of that week (December 31, December 30, etc.) in that new year’s week while some people cut the week into two parts (last year’s part and new year’s part).
Some define week # 1 as the earliest week that contains the first day of the week. Of course that first day of the week is defined by cultural norms such as Sunday in the United States.
Some people define week number 1 as the first complete week of the year, having no days from the previous years. So January 1, January 2, and so on may be counted in the last year.
Some industries and some companies define their own weeks of the year. Some are predictable with a pattern that can deterministically be projected out into the future, while some are arbitrary and defined by humans every year or two or three.
Until the 1990s, the Eastman Kodak Company for decades used and promoted a very different calendar system, the International Fixed Calendar. This system provides for a year of 13 months of 28 days each (exactly 4 weeks), with every date fixed always on the same weekday. So every year has week # 1 starting on Sunday January 1.
The French Republican Calendar is another different calendar in use for over a decade, with a ten-day week.
Keep your mind open, to make sense of date-time matters such as this. Understand that while a day is defined by nature (spinning of the earth) and a year is defined by nature (Earth’s orbit around the Sun), weeks and months and such are inventions of humans. The definition is subject to human creativity and to human folly (ex: Daylight Saving Time nonsense).
Being a standard, it's standardized. Same everywhere.
See Wikipedia page.
My customer wants to display week numbers as they show up in his wall calendar:
Week #1 starts on 1st January
Last week of the year (#53 or #54) ends on 31st December
All other weeks start on Monday and end on Sunday
(As a consequence, first and last weeks do not necessarily have 7 days.)
Does this week number algorithm have a name?
Clarification: I already have PHP code to calculate it, I'm just curious about whether this way of identifying weeks has a commonly accepted name.
There isn't one - that is a completely off-the-wall approach to week numbers. Weeks normally start either with Monday or Sunday when using the Gregorian Calendar. They do not start midway. This is not a criticism of your customer, but a comment on the fact that people invent new ways looking at date arithmetic. And get in trouble migrating to new systems.
RFC 3339
http://www.ietf.org/rfc/rfc3339.txt
See also ISO 8601
I don't understand the way the API returns values. Here's a sample of a page_impressions call, with 'week' as the period.
"values"=>
[{"end_time"=>"2012-01-08T08:00:00+0000", "value"=>1116},
{"end_time"=>"2012-01-09T08:00:00+0000", "value"=>1171},
{"end_time"=>"2012-01-10T08:00:00+0000", "value"=>1175}]
It seems that they're showing how many hits I had in the last 7 days up to the date in "end_time", is that correct? If it is, then I don't understand what use this would have, there is a huge overlap in the data.
How can I get the number of impressions of the last weeks instead? And how can I get more than 3 values to display? I really can't understand the logic behind this or how it could be useful.
What's happening here is that you're being given the total number of page_impressions for the 7-day period ending on each of the dates shown (i.e., how many times was the page seen over the past 7 days assuming the week ended on the end_time? and then on end_time+1? end_time+2)
Facebook is returning three (3) separate readings, presumably so you can spot/review very local trends (e.g., "are my weekly impressions creeping up?) or perhaps because you missed a measurement and want to have values for every day.
To answer your question specifically:
The 7-day period 2012-01-01 through 2012-01-08 12:00am* had 1,116 impressions.
The 7-day period 2012-01-02 through 2012-01-09 12:00am* had 1,171 impressions.
The 7-day period 2012-01-03 through 2012-01-10 12:00am* had 1,175 impressions.
As is quoted below, the end_time itself is always midnight in PDT. Thus, an end_time of 2012-01-08 really means the measurement stopped the night before, i.e., at 1 minute past 11:59pm on 2012-01-07.
From https://developers.facebook.com/docs/reference/fql/insights/:
The end of the period during which the metrics were collected,
expressed as a UNIX time (which should always be midnight, Pacific
Daylight Time) or using the function end_time_date() which takes a
date string in 'YYYY-MM-DD' format. Note: If the UNIX time provided is
not midnight, Pacific Daylight Time, your query may return an empty
resultset. Example: To obtain data for the 24-hour period starting on
September 15th at 00:00 (i.e. 12:00 midnight) and ending on September
16th at 00:00 (i.e. 12:00 midnight), specify 1284620400 as the
end_time and 86400 as the period. Note: end_time should not be
specified when querying lifetime metrics.
Is there a function in Haskell that will allow me to enter component of a date (like a string representation or day month year components) that I can get information from (like day of week, days in a month, etc.)?
I've looked online and it looks like there are a lot of custom libraries, but I'm hoping there's one in the standard prelude library of ghci 10.6.4 that's just not well documented?
Are Data.Time.Calendar and Data.Time.Format in the time library sufficient?
You can parse a string representation of a date and get the length of a month using gregorianMonthLength. Not sure about day of the week, though you could format the date as a string using a format that just displays the week day.
A quick Google search turns up this, which may be what you want. It lets you parse strings representing dates and extract information from them.
You can find the day of the week with mondayStartWeek or sundayStartWeek, depending on whether you think a week starts on Monday, or on Sunday. Both functions are in Data.Time.Calendar.OrdinalDate.
λ> snd $ mondayStartWeek $ fromGregorian 2017 10 3
2
In the above example, the return value is 2, which indicates the second day of the week. Since the function is called mondayStartWeek, Monday is the first day, so 2 corresponds to Tuesday. This is true of October 3, 2017.
A warning regarding week numbers
Both functions return a tuple, where the second element is the week day. As far as I can tell, that should be trustworthy.
The first element, however, is the week number of the year. Be careful with that, because the rules for week numbering are political. If I remember correctly, in USA, week 1 is the week that contains January 1. That's not the case in Denmark, where I live. Here, week 1 is the first week where Thursday falls in the new year. This can mean that December 31 can fall in week 1 of the next year. IIRC, this is the rule for many other European countries. Some years, the American and the European week numbers align, but some years, they don't.