Jump to content

Talk:System time

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Leap seconds

[edit]

"Library subroutines that handle such conversions may also deal with adjustments for... leap seconds"

I doubt it. - lingwitt, 2007-01-17

Some systems do, but most don't. UTC civil time includes leap seconds, even though most (but not all) computer systems simply ignore them. The Network Time Protocol (NTP) time-keeping standard includes leap second adjustments. The standard C library allows for such adjustments, but does not require them. There are many discussions about this among various technical Internet newsgroups ([1] [2] [3] [4] [5]). Most programmers (I perceive) don't like leap seconds, and in fact there are movements underway to eliminate them from civil time reckoning, but the issue is far from resolved (see www.ucolick.org). — Loadmaster 18:09, 23 January 2007 (UTC)[reply]
I must admit that I don't understand the controversy: we already have time keeping without leap seconds: TAI. Why would civilians want this anyway? It is only useful to non-civilian enterprises. In any case, check out an earlier post of mine.
the reason is that in software it's nice to have an unambigious mapping from a time_t value to a date/time. You don't have that right now...if someone sends a time_t number, you have to hope they used the same leap-second policy as you will use. Then there is the simplicity of calculating duration when the number of seconds in a day is constant. finally, lots of clocks in the computing world assume monotonically increasing time. When things go backwards, they get, well, confused. —The preceding unsigned comment was added by SteveLoughran (talkcontribs) 15:41, 11 April 2007 (UTC).[reply]

Early PCs lacking clocks

[edit]

I removed the following edit by 70.228.163.254:

... (however, the Commodore 64 and Commodore 128 both had time-of-day clocks and precision 32 bit interval timers).

The point of that paragraph is to point out that early PC hardware did not track system time. Obviously, later hardware and operating systems did, but it is pointless to list any of them in this article. — Loadmaster (talk) 20:31, 25 November 2007 (UTC)[reply]

RTC interrupt (IRQ8) relevant in Retrieving system time?

[edit]

I edited the table to correct some inaccuracies, but I end up asking myself why is the RTC periodic interrupt (which occurs at 1,024 Hz if the CMOS clock is so programmed) categorized as a way to retrieve system time?

Sure it is nice to note that such timescale exists in addition to all others, but then we can also (in fact we really should, since there is much more confusion in the readership here) mention the FAT timestamp used for files, which is restricted to 2-second resolution. AntoineL (talk) 17:26, 7 January 2008 (UTC)[reply]

Agreed, the table should list calls only for retrieving the system time. So I removed the BIOS INT 70h entry. Otherwise, someone might be tempted to list the clock interrupts for other systems, which would be off-topic. — Loadmaster (talk) 23:23, 18 February 2008 (UTC)[reply]
FWIW, because hooking the clock interupt was a common way of retrieving the system time on DOS systems. PC BIOS is not normally re-entrent, so any TSR which wanted the system time COULD NOT USE PC BIOS after startup. Hence the requirement to hook a timer interupt to get current system time. Normal procedure, because that's how TSRs have to operate anyway.
Uhhhh... no. If the TSR needs to do something on a tick timer rather than hooking something useful it should be passing control to the original interrupt when done, and if it needs to get the time it can either directly call the next in the chain, or use int 1Ah, or disable NMI and read the CMOS, etc... TSRs almost never need to hook something in order to just use it. But this whole discussion (and half the page) is kinda impressively outdated anyway so whatever. --A Shortfall Of Gravitas (talk) 21:48, 6 April 2020 (UTC)[reply]
Don't know about 'other systems' did they require use of a clock interupt if you wanted to display the current time in a secondary process? — Preceding unsigned comment added by 120.148.53.251 (talk) 18:52, 2 January 2012 (UTC)[reply]

History

[edit]

Does anyone have a good reference as to what system(s) was the first to track system time? It would make a good start for a "History" section, which could include the current paragraph that mention early PC systems. — Loadmaster (talk) 01:40, 26 March 2008 (UTC)[reply]

CURRENTDATE

[edit]

The article's first section (Retrieving system time) begins with

According to the Wikipedia system clock, the current time is 20:16, Saturday, November 23, 2024 (UTC).

This does not work so well for users browsing anonymously, as explained in WP:BYPASS#Server cache, though it works great for users who are logged in. Basically, all anonymous users see the same page—preferences do not affect the layout—so Wikimedia's squid (software) serves up the cached copy of the page. They'll see the time when it was cached. Updating the page (making an edit) also causes the cache to update, so that's why it sometimes seems to work. —EncMstr (talk) 20:04, 2 May 2008 (UTC)[reply]

It's also interesting to Google for this page as it appears in other online references, which gives the time that those copies were last retrieved from Wikipedia. — Loadmaster (talk) 20:20, 17 June 2008 (UTC)[reply]

I restored the mention of the Wikipedia system clock, stating that it is the time that the page was last generated (and cached), instead of saying that it is the current time. — Loadmaster (talk) 19:39, 14 November 2008 (UTC)[reply]

correcting C# tick resolution

[edit]

The table summing up the tick resolutions says that C#'s resolution is 10 msec. However, the online documentation tells that the resolution is 100 nanoseconds. I'm going to correct the values for C# and Visual Basic. And Powershell, while we're at it. —Preceding unsigned comment added by Ruijoel (talkcontribs) 08:23, 28 May 2008 (UTC)[reply]

System time / dates format

[edit]
This discussion was copied from User talk:Jc3s5h, 2009-10-22

Jc3s5h mentions in his edits to System time that the date form "DD Mon YYYY" is to be prefered over "YYYY-MM-DD". That's fine, except that the actual dates supported by the operating systems and languages almost never provide actual historically accurate dates prior to 1582 (or 1752, whichever), but almost always use a proleptic calendar algorithm. So it is probably inaccurate to say that, for example, MS Windows and COBOL support dates from 1 Jan 1601 because they probably support only proleptic Gregorian dates back to 1601-01-01 (which is not 1 Jan 1601). The form "1 Jan 1601" implies a historical date, whereas the form "YYYY-MM-DD" is arbitrary (accoring to ISO 8601 rules) and can represent a proleptic date. — Loadmaster (talk) 22:36, 23 September 2009 (UTC)[reply]

Which date to regard as the switchover from Julian to Gregorian depends on the article. Since computer operating systems as a group are not tied to any particular country, the most reasonable date to regard as the first Gregorian date is 15 October 1582, which is the date Gregory XIII ordered it to go into effect. There are a variety of more recent dates when the calendar went into effect in various countries; it didn't go into effect in Greece until 1923. If you wish, you could put a note somewhere in the article that all dates are (proleptic) Gregorian.
There is an advantage to not including such a note, however. By not stating whether a date is Gregorian or Julian is intended unless the documentation has been read to be sure which it is, the ambiguity lets the reader know that the editors who wrote the article have not checked, and in the case of early dates, the reader should investigate which calendar was used. --Jc3s5h (talk) 23:00, 23 September 2009 (UTC)[reply]
I see your point, but I'm arguing that the "YYYY-MM-DD" form is technically the more correct form to use in that particular article because it does not imply actual historical dates. Should this discussion be moved to the talk page? — Loadmaster (talk) 02:26, 24 September 2009 (UTC)[reply]
The YYYY-MM-DD date is inappropriate for the article because there is no telling what it implies. Some people see that format, and think ISO 8601 applies to it, even though Wikipedia has never adopted that standard. If the standard did apply, conformance would require reaching an agreement with the readers that we could use it for any date outside the range 1583 through 9999, and no such agreement has been formed.
I don't really understand when you say "it does not imply actual historical dates." Can you amplify? --Jc3s5h (talk) 02:40, 24 September 2009 (UTC)[reply]
Since ISO 8601 format does not imply a particular (agreed upon) interrepretation of Gregorian calendar dates, it does not automatically imply historically accurate dates. E.g., saying "1601-01-01" by itself does not imply the actual historical date of 1 Jan 1601 according to the historical Gregorian calendar(s). "Reaching an agreement with the readers" is as simple as providing a footnote in the article stating that the dates do not align with historical dates but are (typically) based on the proleptic Gregorian calendar. Rewriting the dates in "DD Mon YYYY" form does not buy us any more clarity. — Loadmaster (talk) 17:53, 25 September 2009 (UTC)[reply]
Writing "1601-01-01" by itself does not imply adoption of ISO 8601, and therefore there is no implication that the date is a Gregorian date. If it were written in a context where ISO 8601 applied, then it would indicate January 1, AD 1601, in a year numbering system where the new year begins January 1, local time (but the locality would have to be discerned from the surrounding text).
I don't understand what "the actual historical date of 1 Jan 1601 according to the historical Gregorian calendar(s)" means. There is only one Gregorian calendar, in the sense of the sequence of month names, date numbers, leap years, date of Easter, etc. Various countries considered the year to begin at various times while the Gregorian calendar was in force. Long after 1601 some Asian countries adopted the Gregorian calendar but numbered years from some culturally important event, such as the founding of the country. --Jc3s5h (talk) 19:14, 25 September 2009 (UTC)[reply]
The plural "Calendar(s)" was an error on my part. But I still think it's better to use the "YYYY-MM-DD" format than "DD Mon YYYY" in the article. — Loadmaster (talk) 21:50, 28 September 2009 (UTC)[reply]

(unindent)
OK, correcting your statement to the singular, it becomes E.g., saying "1601-01-01" by itself does not imply the actual historical date of 1 Jan 1601 according to the historical Gregorian calendar. "January 1, 1601" in an article that is not associated with any particular country, could mean either the Gregorian calendar or the Julian calendar. Likewise, "1601-01-01", in the absence of any statement about ISO 8601, could mean either Gregorian or Julian calendar. So why is it better to use the later in the article? --Jc3s5h (talk) 22:42, 28 September 2009 (UTC)[reply]

Since you're saying that both formats are therefore equal with regards to historic/non-historic dates, then why is it better to use "DD Mon YYYY"? The form "YYYY-MM-DD" at least has the advantage of being an international standard format. — Loadmaster (talk) 01:44, 29 September 2009 (UTC)[reply]
No decent English-language publication uses the "YYYY-MM-DD" format, and neither should Wikipedia. Furthermore, the format, by itself, is not an international standard. ISO 8601 is an international standard, but Wikipedia has not adopted that standard. If you think Wikipedia should adopt ISO 8601, propose a policy to that effect at Wikipedia:Village pump (policy).
I would oppose such a policy for many reasons, not the least of which is that ISO charges exorbitant fees for copies of its standards, and Wikipedia, as a source of freely available information, should not support such an organization.
Also, while technically ISO 8601 only applies when the publication using the YYYY-MM-DD format says it applies, there are many people, such as yourself, who cannot get it out of their heads that ISO does not own the YYYY-MM-DD format and think ISO 8601 always applies. Since it is impossible to explain this horrible mess to our readers, the format should be banned.
It's like World War II era Jeeps. The Army found that no matter how many warnings were made about the handling characteristics, people who bought surplus Jeeps kept rolling them over. So finally the Army punched big holes in the chasis of scrapped Jeeps to make sure they could never be driven again. --Jc3s5h (talk) 02:09, 29 September 2009 (UTC)[reply]
Wikipedia:DATES covers the formatting guidelines for dates and times. It states that the "dd Month yyyy" or "Month dd, yyyy" forms are the preferred forms for prose text, and that the "yyyy-mm-dd" format is suitable for use in tables and lists. Your arguments for not using a freely usable international format because ISO charges fees to support itself are just silly. — Loadmaster (talk) 19:05, 26 October 2009 (UTC)[reply]

RfC ISO 8601 use in System time article

[edit]

Loadmaster's recent edit adopting the YYYY-MM-DD date format is confusing and/or violates ISO 8601.

  • The edit summary—(→Retrieving system time: restore ISO 8601 date formats, made it clear that these are proleptic Gregorian calendar dates)—asserts the edits comply with ISO 8601.
  • Wikipedia has not adopted ISO 8601 for use in articles; indeed it is contrary to WP:MOSNUM.
  • The article contains no statement that it uses ISO 8601.
  • The article contains dates prior to the year 1583 in contravention of the ISO 8601 standard.

I have reverted the change. --Jc3s5h (talk) 21:13, 26 October 2009 (UTC)[reply]

  • Per WP:MOSNUM, YYYY-MM-DD should not be used for any date before 1583. To comply with the MOS, such dates must be written out in full. Given that the MOS also has rules favouring consistency, there is no way in which this article can be made MOS-compliant with YYYY-MM-DD style dates. I don't see any reasonable IAR basis to consider this article an exception to this rule - unless there is one all dates should be written out. Note that, to many people, YYYY-MM-DD does not necessarily imply the proleptic Gregorian calendar: the ISO standard is not that well known. Pfainuk talk 22:26, 26 October 2009 (UTC)[reply]
  • The altered version of the article did include a statement that all dates were (proleptic) Gregorian, so that in itself was not a problem. But all Pfainuk's other points are valid. --Jc3s5h (talk) 22:37, 26 October 2009 (UTC)[reply]
ISO 8601 format can indeed be used for dates, as long as it's made clear to the reader that they do not represent historically accurate dates. This qualifies as "agreement between parties" as described in the ISO 8601 article. Furthermore, WP:DATES makes it clear that ISO 8601 format dates can be used in tables and lists (as long as it's made clear that they are proleptic Gregorian dates). Also, we're talking about an article dealing with a technical subject (retrieving the system time from a computer), so we can assume a certain level of technical understanding on the part of the reader. A final point is that the dates in the tables should be indicated as being proleptic Gregorian calendar dates, because they are not historically accurate dates (e.g., 1 January 1601 and 1 January 0001). — Loadmaster (talk) 01:51, 27 October 2009 (UTC)[reply]
What is a "historically accurate date"? --Jc3s5h (talk) 01:57, 27 October 2009 (UTC)[reply]
For example, 1 Jan 1601. Unless it's stated otherwise, it can be assumed by the reader to mean the actual (historical) day of 1 Jan 1601, presumably within either the Gregorian calendar (in Europe) or the Julian calendar (in the UK and its territories) depending on the context. If it's made clear, however, that it's a date within the proleptic Gregorian calendar, they it does not represent the historical day of 1 Jan 1601, but rather exactly 400 years' worth of days (146,097) prior to 1 Jan 2001 (i.e., in the previous 400-year Gregorian cycle). That's why articles about computer dates and times (e.g., Unix time) should carry an explanation of what calendric and time-keeping system is being used, as compared to articles dealing with historical events (e.g., the birth of George Washington or the October Revolution), which typically employ dates according to an actual historical calendar in use at the time of the event. — Loadmaster (talk) 02:39, 27 October 2009 (UTC)[reply]
So, if I say "1 January 1601 in the proleptic Gregorian calendar" it is not a historical date, and thus I am a liar if I am referring to a date in Europe, is that what you mean? --Jc3s5h (talk) 03:38, 27 October 2009 (UTC)[reply]
"Mon 1 Jan 1601" in the proleptic Gregorian calendar designates the historical day "Fri 22 Dec 1600" in most of Europe and "Sun 21 Dec 1600" in the UK. — Loadmaster (talk) 16:57, 27 October 2009 (UTC)[reply]
I shouldn't have said Europe, because some European countries had adopted the Gregorian calendar and some had not; it would take some research to decide if "most" had retained the Julian calendar. In any case, the phrase "proleptic Gregorian calendar" shouldn't be applied to a time and place where the Gregorian calendar was in force. --Jc3s5h (talk) 17:51, 27 October 2009 (UTC)[reply]
A minor historical quibble. The change in calendar did not affect the continued progression of days of the week. In most if not all of Catholic Europe, that date was Mon 1 January 1601. In the rest of Europe, including England and Scotland, that date was Mon 22 December 1600. Pfainuk talk 18:51, 27 October 2009 (UTC)[reply]
You are incorrect. Mon 1 Jan 1601 in the proleptic calendar is exactly 146,097 days before Mon 1 Jan 2001. This does not coincide with a Monday in either the Julian or the Gregorian calendar in effect at the time, because there is a difference of 10 or 11 days between those calendars and the proleptic calendar (i.e., the historic calendars omit some days while the the proleptic calendar does not). — Loadmaster (talk) 03:02, 28 October 2009 (UTC)[reply]
Rubbish. Pfainuk is right. Since the 7-day week was generally introduced, there have never been any discontinuities, EXCEPT for people or locations that crossed the Date Line. Example : two consecutive local solar days in 1867 Alaska were necessarily the same number CMJD and the same day of the week (probably 3257 Friday; 1867/10/06 Julian then 1867-10-18 Gregorian). And Loadmaster (talk) 16:57, 27 October 2009 (UTC) is also wrong. 82.163.24.100 (talk) 13:15, 17 December 2010 (UTC)[reply]
Scotland switched to a legal year beginning 1 January in 1600. --Jc3s5h (talk) 21:31, 27 October 2009 (UTC)[reply]
There is no such requirement for 4-digit year numbers. — Loadmaster (talk) 02:39, 27 October 2009 (UTC)[reply]
I read section 4.1.2.4 to mean that if one is going to represent any year of 5 digits or more (either positive or negative) then a maximum number of digits must be agreed to and all years must use that number of digits. Please explain the error in my reading. --Jc3s5h (talk) 03:42, 27 October 2009 (UTC)[reply]
So what? It is possible to use dates in the ISO 8601 format without following the ISO 8601 standard, much like it is possible to use SI units without following the SI recommendations (I've lost more than 4% of my weight since June, now I'm about 85 kg — note the lack of a space before the percent sign). In fact, there are many people (mostly programmers and East Asians) using such dates who have never heard of ISO 8601. ___A. di M. 10:04, 27 October 2009 (UTC)[reply]
The problem is that the format without the standard is an informal understanding that only applies to dates close to the 21st century. There is no understanding established about what to do with ancient dates, or dates in the distant future. Since a discussion of system time includes such dates, the article includes dates for which no informal understanding exists. Also, I notice Loadmaster has decided not to answer my question. --Jc3s5h (talk) 17:57, 27 October 2009 (UTC)[reply]
I agree with A. di M.. We're talking about what formats to use, not what standards to follow. If we use the "yyyy-mm-dd" format, that does not automatically imply that we're bound by all the rules encompassed by ISO 8601. I prefer the "yyyy-mm-dd" format for reasons of clarity and conciseness. — Loadmaster (talk) 18:21, 27 October 2009 (UTC)[reply]

My two cents: as long as it's made clear that dates are in the prolectic Gregorian calendar, I can see nothing wrong with YYYY-MM-DD. But I can't see any strong reason not to use English language dates (except that they take up more space). (A quibble: In spelt-out dates I'd use AD 1 rather than 1 etc. for years before 100 for clarity.) BTW, has anyone considered 01 Jan 0001? ___A. di M. 10:04, 27 October 2009 (UTC)[reply]

"1 January 0001" looks less ambiguous than "1 January 1", but I find no rule either way. — Loadmaster (talk) 17:10, 27 October 2009 (UTC)[reply]
I don't see that 1 January 1 is particularly ambiguous - the only possible ambiguity is whether we're dealing with AD 1 or 1 BC as both numbers are ones (and in context one would suggest that 1 BC is unlikely) - but that doesn't mean that it's not going to make readers do a double take. Readers are more likely to understand that 0001 is the year, but that doesn't make it any less strange and doesn't make the date as a whole less ambiguous. I would suggest that AD 1 or 1 AD are better per A di M. Pfainuk talk 18:38, 27 October 2009 (UTC)[reply]
Yeah, I see that the only date whose year has fewer than three digits is 1 January 1, which is indeed unambiguous. "1 January 2" could mean "AD 1 January the 2nd" (as in Metre#Timeline of definition; that's a rare format, but not a non-existent one, especially in Canada); and "1 January 12" could mean "1 January '12" (i.e. 1912, 2012, etc.) if someone forgot an apostrophe. Now the reader can determine that this is not the case by comparing it to other dates, but putting in that "AD" would make that determination immediate. Never mind, then. ___A. di M. 14:27, 28 October 2009 (UTC)[reply]

Two comments:

  • WP:MOSNUM#Dates says, "... [ISO 8601 format] should never be used for a date that is not in the (proleptic) Gregorian calendar, nor for any year outside the range 1583 through 9999." (emphasis added)
  • WP:MOSNUM#Year numbering systems says, "Do not use CE or AD unless the date would be ambiguous without it. E.g., 'The Norman Conquest took place in 1066.' not 1066 CE or AD 1066." I would apply that to the case of '1 January 0001' as meaning that in the absence of a BC or BCE suffix, that date is presumed to refer to an AD or CE date and is therefore considered to be unambiguous.

I see that the article has been edited to return to the the Monthdate Monthname YYYY date format, so these comments are moot re the current version of the article. Wtmitchell (talk) (earlier Boracay Bill) 02:44, 28 October 2009 (UTC)[reply]

Well, this is a discussion about what is the best format to use, the longer form ("DD Mon YYYY") or shorter form ("YYYY-MM-DD"). I doesn't look like the issue is resolved yet. — Loadmaster (talk) 03:02, 28 October 2009 (UTC)[reply]
I'd say it's a contest between a defined format and an undefined format. Everyone knows what to write using the "DD Mon YYYY" format for ancient dates like 1 January 1 or 1 January 1 BC, or the year 292,277,026,596. Since those who use the informal format "YYYY-MM-DD" seldom, if ever, deal with such extreme dates, no one knows what to write. Of course, there is always the ISO 8601 standard, but Loadmaster has already rejected the idea of following that rigorously.
Furthermore, "DD Mon YYYY" has the advantage of being one of the preferred formats in WP:MOSNUM. Jc3s5h (talk) 14:01, 28 October 2009 (UTC)[reply]

Meaning of proleptic Gregorian calendar

[edit]

Loadmaster wrote at 03:02, 28 October 2009 (UTC)[reply]

You are incorrect. Mon 1 Jan 1601 in the proleptic calendar is exactly 146,097 days before Mon 1 Jan 2001. This does not coincide with a Monday in either the Julian or the Gregorian calendar in effect at the time, because there is a difference of 10 or 11 days between those calendars and the proleptic calendar (i.e., the historic calendars omit some days while the the proleptic calendar does not).

This indicates a serious misunderstanding of the term proleptic Gregorian calendear. Yes, the Julian date converter at the United States Naval Observatory, with a simple subtraction, does show there are exaclty 146,097 days between 1 January of 1601 and 2001. Yes, the Astronomical Almanac for the year 2001 confirms 1 January was indeed a Monday. Since 146,097 days is exactly 20,871 weeks, 1 January of 1601 was a Monday in places observing the Gregorian calendar (Italy, Spain, Portugal, Poland, France, Austria, and various other areas). This comes from Gingerich, (1983), "The Civil Reception of the Gregorian Calendar" in Coyne, Hoskin, & Pedersen (eds.) Gregorian Reform of the Calendar, Vatican Observatory, pp. 265–6. Loadmaster's statement above indicates there is some other, proleptic, Gregorian calendar that could be applied to 1 January 1601 in a place, like France, that was observing the Gregorian calendar at the time. There is no such thing. The proleptic Gregorian calendar is merely applying the rules of the Gregorian calendar backward from some convenient date when it was in force (such as today) to a date when it was not in force. --Jc3s5h (talk) 05:07, 28 October 2009 (UTC)[reply]

The statement that "historic calendars omit some days while the the proleptic calendar does not" is quite true, but for the places observing the Gregorian calendar in 1601, the omission had already happened circa 1583, so counting backwards from today to 1601 by Gregorian rules does not encounter the omission. (However, Italy in 1601 had not adopted January 1 as the date the year number changes; most of continental Europe had.) Jc3s5h (talk) 05:07, 28 October 2009 (UTC) Modified 14:18, 28 October 2009.[reply]

Indeed. I'd also add that, while year numbering may have been different, the dates and months used legally prior to the changeover were the same all over Europe. Deducting eleven days from 1 January 1601 will not get you the legal date in England at that time because the difference was only ten days. When Britain changed over in 1752, it had to lose the ten days that France and Spain did plus one to represent 29 February 1700 (legally 1699 in England because of the way years were numbered) - skipped under Gregorian rules but not Julian rules. When Russia changed over in 1918, it had to skip 13 days, because the Julian calendar leap years in 1800 and 1900 as well. Pfainuk talk 18:52, 28 October 2009 (UTC)[reply]
For reference, this is the month of September 1752 in the UK, when it adopted the Gregorian calendar (as produce by the Unix cal command):
   September 1752
Su Mo Tu We Th Fr Sa
       1  2 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
11 days are omitted between Wed and Thu of the first week. Thus counting backwards (proleptically) to a date prior to 1752-09-14, such as to 1601-01-01, requires accounting for the missing (or extra, depending on which way you're converting) 11 (or 10) days. The sequence of weekdays remains uninterrupted, but there is a discontinuity in the dates. — Loadmaster (talk) 22:45, 28 October 2009 (UTC)[reply]
The discontinuity in civil time at September 2–14, 1752, was eleven omitted days; the discontinuity in civil time at October 4–15, 1582, was ten omitted days. Various other discontinuities exist, depending on when the Gregorian calendar was adopted. One would never use a ten day correction in connection with the 1752 discontinuity. Also, with a few exceptions for places that changed their minds or were conquered (like Montreal), only one discontinuity applies to any given place. --Jc3s5h (talk) 23:04, 28 October 2009 (UTC)[reply]
Right. But when converting a given date between calendars, one must take account not of the days omitted when a country converted between calendars but of the difference between the calendars at that the date you're converting. We would not say that the Old Style date today was 19 October in France, 18 October in Britain and 16 October in Russia - that would be inaccurate. Rather, had the Julian calendar still been in force today in these countries, all three would agree that today's date would be 16 October.
Compared with the Julian calendar, Italy omitted ten days in 1582, plus one each in 1700, 1800 and 1900. Britain kept the one in 1700 but made it up by skipping an extra day in 1752 - 11 days instead of 10. Russia has never yet missed out a leap year day according to the Gregorian rule, rather it skipped 13 days in 1918. In all three cases, the total difference between Old Style and New Style as of today is 13 days.
From 1500-1700 the difference between the two calendars was ten days. It was 10 days in England and it was 10 days in Italy. The difference was which of the two calendars one used after 1582 - England was ten days (not eleven) behind Italy until 1700. As such, assuming that years all begin on 1 January (a reasonable simplification) the proleptic Gregorian date Mon 1 January 1601 coincides with the historical date Mon 1 January 1601 in most of Catholic Europe and the historical date Mon 22 December 1600 in the rest of Europe. Pfainuk talk 18:40, 29 October 2009 (UTC)[reply]
[edit]

There are other date/time pages at http://www.merlyn.demon.co.uk which might be considered to be at least as germane as CritDate. 82.163.24.100 (talk) 13:00, 17 December 2010 (UTC)[reply]

Operating Systems

[edit]

2-12 μs is NOT 244.14 ps; I believe the latter. 82.163.24.100 (talk) 13:19, 17 December 2010 (UTC)[reply]

Yes, it is. The key to understanding this is that the operation of raising 2 to the negative 12 power is performed first, and then the μs unit is associated with the resulting number. So it is 2.44 ×10−4 μs which is equal to 244 ps. Jc3s5h (talk) 15:31, 17 December 2010 (UTC)[reply]

Operating systems

[edit]

Epoch or range column :

Needs a clear indication of whether UTC, GMT, local, or other.

"Midnight of the current day" is in principle ambiguous. Use "Start", "Beginning" or "00:00".

In several cases, the end is not at 00:00 - that should be indicated.

Next table : JavaScript - new Date() seems better. Range is +- 10^8 days.

82.163.24.100 (talk) 13:28, 17 December 2010 (UTC)[reply]

I addressed this for IBM z/Architecture, which uses UT. For current systems it uses UTC, but that did not exist for the entire time range, and might not exist for the remainder of the time range. For information about possible changes to, and renaming of, UTC, see Leap second. Jc3s5h (talk) 16:12, 17 December 2010 (UTC)[reply]

Citation format

[edit]

This article does not appear to follow any particular citation format. The first citation was added in this edit, and appears to be a plain-language description of the source rather than following any recognized style. So if I were to standardize the format, what format should I use? Jc3s5h (talk) 12:30, 17 October 2011 (UTC)[reply]

Per WP:CITE#Citation style, there is no agreed upon standard. Use whichever you are most comfortable with. —EncMstr (talk) 16:23, 17 October 2011 (UTC)[reply]
I have made the citations consistent, using The Chicago Manual of Style. Jc3s5h (talk) 16:47, 27 October 2011 (UTC)[reply]

Resolution column in tables

[edit]

There is a distinction between the resolution or granularity at which a system keeps or reckons time, and the resolution with which time is reported. For example, in Microsoft Windows, GetSystemTimeAsFileTime indeed returns a 64-bit integer that reflects the number of 100 nsec intervals since 01 Jan 1601. However the system does not keep time with anything like that fine a granularity; timekeeping is driven by an interval timer interrupt with a typical default period of 15.625 msec (64 Hz), settable to as little as 1 msec or 0.5 msec for software that needs better resolution.

This distinction should be made in the table that compares operating systems. I suggest three adjacent columns, labeled perhaps "Resolution (reported)", "Resolution (implemented, default)", and "Resolution (implemented, best)". I have only information on Windows and VMS so I can't make much of a start here. I suggest that we add information to this section and then make the change to the article when enough cases are described so that we don't have a mostly-empty column. Jeh (talk) 18:33, 8 July 2012 (UTC)[reply]

You are talking about the difference between resolution and precision. As the tables stand now, it is more relevant to display the units returned by the OS or programming language call, i.e., the resolution, and footnotes should suffice for explaining the actual accuracy/precision of the value returned by the call. For future editions of the tables, though, instead of adding another column we should perhaps expand the "Resolution" column to include both, i.e., "Resolution and Precision", which displays the resolution (time units returned by the call) and also parenthetically displays the range of actual/expected accuracy. Perhaps using a notation such as "1ms ±10ms" (specifying a resolution of 1ms and a precision of 10ms) might also suffice. — Loadmaster (talk) 18:04, 11 July 2014 (UTC)[reply]