EEVblog Electronics Community Forum
General => General Technical Chat => Topic started by: VinzC on July 16, 2017, 01:37:14 pm
-
I've just watched Dave's EEVBlog2 World Time Zones explained (https://www.youtube.com/watch?v=iSHHe-AXxqw) (World Time Zones explained).
If that sounds interesting, developers should never attempt at writing code for managing time zones though. You'll find why in an excellent video made by Tom Scott (https://www.youtube.com/watch?v=-5wpm-gesOY) (Tom Scott, Computerphile).
-
Anything to do with time and dates is more difficult than you imagined. And that includes recursion.
Let's start with simple questions:
- how many milliseconds are there in a second?
- how many seconds are there in a minute?
- how many minutes are there in an hour?
- how many hours are there in a day?
- how many days are there in a month?
- how many months are there in a year?
- how many years are there in a century?
-
Anything to do with time and dates is more difficult than you imagined. And that includes recursion.
Let's start with simple questions:
- how many milliseconds are there in a second?
- how many seconds are there in a minute?
- how many minutes are there in an hour?
- how many hours are there in a day?
- how many days are there in a month?
- how many months are there in a year?
- how many years are there in a century?
Well, the answer is simple. It just depends on where you are and when you ask the question.
-
Anything to do with time and dates is more difficult than you imagined. And that includes recursion.
Let's start with simple questions:
- how many milliseconds are there in a second?
- how many seconds are there in a minute?
- how many minutes are there in an hour?
- how many hours are there in a day?
- how many days are there in a month?
- how many months are there in a year?
- how many years are there in a century?
Well, the answer is simple. It just depends on where you are and when you ask the question.
Assume here and now. What's your answer?
-
Assume here and now. What's your answer?
Define "here" and "now"? Is it your "here" or mine? Is it the "now" you typed the question or the "now" I'll post the reply? Shall I account for the propagation delay and the case my reply takes more than 4 months (and I switch to winter time). Hmmm... I need a couple of weeks to reply ;-) .
-
Assume here and now. What's your answer?
Define "here" and "now"? Is it your "here" or mine? Is it the "now" you typed the question or the "now" I'll post the reply? Shall I account for the propagation delay and the case my reply takes more than 4 months (and I switch to winter time). Hmmm... I need a couple of weeks to reply ;-) .
All valid, but none of that changes the answers :)
-
All valid, but none of that changes the answers :)
Of course it does. Some places observe daylight savings, others do not.
Anything to do with time and dates is more difficult than you imagined. And that includes recursion.
Let's start with simple questions:
- how many milliseconds are there in a second?
- how many seconds are there in a minute?
- how many minutes are there in an hour?
- how many hours are there in a day?
- how many days are there in a month?
- how many months are there in a year?
- how many years are there in a century?
Assuming we are talking UTC (so no daylight savings or politicians changing timezones):
- 1000 milliseconds in a second
- 59, 60 or 61 seconds in a minute (leap seconds)
- 60 minutes in an hour
- 24 hours in a day (may be 23 or 25 if daylight saving is observed)
- between 27 and 31 days in a month.
- 12 month in a year*
- 100 years in a century
What pitfalls did I miss (step into)?
*) assuming Gregorian year. A year as part of an ISO 8601 week date may last until January of the next Gregorian year and may have 13 or maybe even 14 (partial) months.
-
I would recommend against using UTC, the length of the day varies considerably during the year due to the earth's rotation varying.
I would advise https://en.wikipedia.org/wiki/Barycentric_Dynamical_Time
;)
PS
1000 milliseconds in a second
Nothing wrong with that statement... in fact it is the definition of a milli. 1000 milliaardvarks in an aardvark
-
All valid, but none of that changes the answers :)
Of course it does. Some places observe daylight savings, others do not.
Anything to do with time and dates is more difficult than you imagined. And that includes recursion.
Let's start with simple questions:
- how many milliseconds are there in a second?
- how many seconds are there in a minute?
- how many minutes are there in an hour?
- how many hours are there in a day?
- how many days are there in a month?
- how many months are there in a year?
- how many years are there in a century?
Assuming we are talking UTC (so no daylight savings or politicians changing timezones):
- 1000 milliseconds in a second
- 59, 60 or 61 seconds in a minute (leap seconds)
- 60 minutes in an hour
- 24 hours in a day (may be 23 or 25 if daylight saving is observed)
- between 27 and 31 days in a month.
- 12 month in a year*
- 100 years in a century
What pitfalls did I miss (step into)?
In the UK, 1752 had 10 fewer days. I've heard tales that the tax year boundary used to be the equinox, and rather than change the amount of tax gathered, they kept the tax year the same length. Currently the tax year boundary is April 5th/6th.
Practically you have to include DST; hence 23/24/25 is correct.
Different definitions of days and lunar months, of various types - but they aren't part of the calendar.
*) assuming Gregorian year. A year as part of an ISO 8601 week date may last until January of the next Gregorian year and may have 13 or maybe even 14 (partial) months.
How narrow minded and parochial; a common fallacious assumption :)
One calendar has up to 19 months of 19 days - plus a 4 or 5 days that aren't in months.
-
I would recommend against using UTC, the length of the day varies considerably during the year due to the earth's rotation varying.
Sometimes UTC is precisely the most appropriate definition of time; it all depends on how you are using time.
1000 milliseconds in a second
Nothing wrong with that statement... in fact it is the definition of a milli. 1000 milliaardvarks in an aardvark
Not quite as simple as that. Leap seconds are added/subtracted at convenient instants, not when a definition of time has shifted by 1000ms.
-
Not quite as simple as that. Leap seconds are added/subtracted at convenient instants, not when a definition of time has shifted by 1000ms.
Seconds are always 1000 milli-seconds long by definition. Indeed Seconds are well defined too... 9192631770 periods.... Cs133.... etc.
Leap seconds are a human thing to keep their time in sync with the rotation of the planet they are on. Indeed the extra seconds are added where convenient in order to keep UT1 and UTC reasonably close together (DUT1). When an extra second is added... it is always the same size as the others and its likewise 1000 as big as 1/1000th of a second.
I'm not saying your seconds appear to be as long as mine.... since it's all relative. (and depends on our velocity/gravitational effects etc). ;)
-
Not quite as simple as that. Leap seconds are added/subtracted at convenient instants, not when a definition of time has shifted by 1000ms.
Seconds are always 1000 milli-seconds long by definition. Indeed Seconds are well defined too... 9192631770 periods.... Cs133.... etc.
Leap seconds are a human thing to keep their time in sync with the rotation of the planet they are on. Indeed the extra seconds are added where convenient in order to keep UT1 and UTC reasonably close together (DUT1). When an extra second is added... it is always the same size as the others and its likewise 1000 as big as 1/1000th of a second.
I'm not saying your seconds appear to be as long as mine.... since it's all relative. (and depends on our velocity/gravitational effects etc). ;)
It's pretty daft measuring time, to any degree of accuracy, in anything but seconds or milliseconds. The calender can easily be modified by using satellites to measure the earth's position, relative to the moon and the sun.
-
Not quite as simple as that. Leap seconds are added/subtracted at convenient instants, not when a definition of time has shifted by 1000ms.
Seconds are always 1000 milli-seconds long by definition. Indeed Seconds are well defined too... 9192631770 periods.... Cs133.... etc.
Leap seconds are a human thing to keep their time in sync with the rotation of the planet they are on. Indeed the extra seconds are added where convenient in order to keep UT1 and UTC reasonably close together (DUT1). When an extra second is added... it is always the same size as the others and its likewise 1000 as big as 1/1000th of a second.
I'm not saying your seconds appear to be as long as mine.... since it's all relative. (and depends on our velocity/gravitational effects etc). ;)
You appear to be confusing durations with calendars. They are fundamentally different and incompatible, despite their using similar units. And therein lies a lot of the complexity :)
-
You appear to be confusing durations with calendars. They are fundamentally different and incompatible, despite their using similar units. And therein lies a lot of the complexity :)
Hm... well I'm certainly not disputing that calendars are confusing... they involve popes and emperors. But they are defined by epoch and duration thereafter so I think they are most certainly related.
-
You appear to be confusing durations with calendars. They are fundamentally different and incompatible, despite their using similar units. And therein lies a lot of the complexity :)
Hm... well I'm certainly not disputing that calendars are confusing... they involve popes and emperors. But they are defined by epoch and duration thereafter so I think they are most certainly related.
Simple example... A one second duration (number of times an ion has waggled its tail) can finish an >hour later than it started, e.g. 00:01:59.5 to 03:00:00.5 Or, of course, finish before it started.
-
Practically you have to include DST; hence 23/24/25 is correct.
Which brings me to my favorite time zone - Troll time (yes, I kid you not - look in /usr/share/zoneinfo/Antartica) - it has +1 and +2 hour Daylight Saving, so you can have two short days and two long days in a year.
-
I would recommend against using UTC, the length of the day varies considerably during the year due to the earth's rotation varying.
I would advise https://en.wikipedia.org/wiki/Barycentric_Dynamical_Time
;)
PS
1000 milliseconds in a second
Nothing wrong with that statement... in fact it is the definition of a milli. 1000 milliaardvarks in an aardvark
Well there goes a few more hours on Wikipedia and in the more obscure corners of the Interweb....
-
Practically you have to include DST; hence 23/24/25 is correct.
Why? Look at this map (https://en.wikipedia.org/wiki/Daylight_saving_time_by_country#/media/File:DST_Countries_Map.png). If you are in any of the light or dark gray countries, then you would not observe daylight saving, and hence a day would be 24 hours (unless politicians mess with the daylight savings, which is incidentally why I picked UTC which does not observe daylight savings either). You refused to specify location, so to me that means the person answering the question can assume any location they wish (I imagine implied that it should be on earth :P). So North Korea, which does not observe daylight savings, would be a valid pick.
-
(http://i.imgur.com/Aj8b9nc.jpg)
Posted on 2017-07-18T06:16:44+00:00
-
Simple example... A one second duration (number of times an ion has waggled its tail) can finish an >hour later than it started, e.g. 00:01:59.5 to 03:00:00.5 Or, of course, finish before it started.
:o Eh? Please explain, I'm curious to understand!
-
Hm... 59682F00 doesn’t really seem worth celebrating
I'm holding out for Wed Dec 25 05:01:21 GMT 2041. It's even Christmas Day.
(PS Although I can understand the obsession humans have for base 10)
-
.
If you can fit one of these in the shed, time zones are not a problem >:D
www.youtube.com/watch?v=qIQVpXYiTuc (https://www.youtube.com/watch?v=qIQVpXYiTuc)
-
Simple example... A one second duration (number of times an ion has waggled its tail) can finish an >hour later than it started, e.g. 00:01:59.5 to 03:00:00.5 Or, of course, finish before it started.
:o Eh? Please explain, I'm curious to understand!
Remember what happened on Sunday, 26 March 2017 at 01:00?
And will happen on Sunday 29 October at 02:00, in the UK?
-
Don't forget to account for general relativity. |O
-
Don't forget to account for general relativity. |O
What do they say? A man with one watch always knows the time, a man with....
How about a man with six atomic clocks in the back of his car? http://www.leapsecond.com/great2016a/ (http://www.leapsecond.com/great2016a/)
-
Don't forget to account for general relativity. |O
... another bag of worms.
And, of course, there's the everyday[1] problem of two clocks separated by a significant distance (and hence time), where "significant" is of the order of the tick duration :) That's a fundamental problem; see Leslie Lamport's seminal work to find out the best that can be achieved.
[1] most frequently seen when trying to decide which version of a file is more recent, in a distributed file system.
-
Simple example... A one second duration (number of times an ion has waggled its tail) can finish an >hour later than it started, e.g. 00:01:59.5 to 03:00:00.5 Or, of course, finish before it started.
:o Eh? Please explain, I'm curious to understand!
Remember what happened on Sunday, 26 March 2017 at 01:00?
And will happen on Sunday 29 October at 02:00, in the UK?
Right, do you mean 01:59:59.5, then?
-
Simple example... A one second duration (number of times an ion has waggled its tail) can finish an >hour later than it started, e.g. 00:01:59.5 to 03:00:00.5 Or, of course, finish before it started.
:o Eh? Please explain, I'm curious to understand!
Remember what happened on Sunday, 26 March 2017 at 01:00?
And will happen on Sunday 29 October at 02:00, in the UK?
Right, do you mean 01:59:59.5, then?
Maybe. Complicated and error prone, this time and calendar stuff :)
-
OK I admit it... interesting things do happen when humans and calendars are involved... I spent my New Year watching 23:59:60
:)
-
Maybe. Complicated and error prone, this time and calendar stuff :)
Agreed. Two things that I would not develop myself if there is any way to avoid it:
- Cryptography
- Time/date handling
-
For me I usually just says F with time zones - it is the last thing I add into my code (along with other i18n/l10n stuff) and the core code is always based on some kind of epoch for time manipulation. Most code uses either UNIX epoch (1970-01-01T00:00:00Z, counting seconds using integers) or NeXTSTEP epoch (https://developer.apple.com/documentation/foundation/nsdate/1409769-init) (2001-01-01T00:00:00Z, counting seconds using double-precision float point numbers.)
-
Maybe. Complicated and error prone, this time and calendar stuff :)
Agreed. Two things that I would not develop myself if there is anyway to avoid it:
- Cryptography
- Time/date handling
We are in violent agreement.
-
For me I usually just says F with time zones - it is the last thing I add into my code (along with other i18n/l10n stuff) and the core code is always based on some kind of epoch for time manipulation. Most code uses either UNIX epoch (1970-01-01T00:00:00Z, counting seconds using integers) or NeXTSTEP epoch (https://developer.apple.com/documentation/foundation/nsdate/1409769-init) (2001-01-01T00:00:00Z, counting seconds using double-precision float point numbers.)
Sometimes it isn't possible to avoid them :(
In one incarnation I was developing soft realtime mobile phone charging systems. The tariff depended on the time of day/week/month/user and marketing whims. If the call is originated in Western Australia, terminated in the UK, and the billing system is in Canada, you have to be very careful which timezone you are meant to be using!
-
In one incarnation I was developing soft realtime mobile phone charging systems. The tariff depended on the time of day/week/month/user and marketing whims. If the call is originated in Western Australia, terminated in the UK, and the billing system is in Canada, you have to be very careful which timezone you are meant to be using!
And then you find out that the energy company was using Microsoft Excel (https://support.microsoft.com/en-us/help/214326/excel-incorrectly-assumes-that-the-year-1900-is-a-leap-year) for billing, and you have to modify your date handling to match theirs :P.
-
I spent too much time explaining to my boss that people on 1st floor should be paid more than people on ground floor,
because the people working on the 1st floor adhered to a clock on the ground floor (with regard to working hours).
-
The same effect causes GPS clocks to run fast by 45us/day... it's a big effect!
-
For me I usually just says F with time zones - it is the last thing I add into my code (along with other i18n/l10n stuff) and the core code is always based on some kind of epoch for time manipulation. Most code uses either UNIX epoch (1970-01-01T00:00:00Z, counting seconds using integers) or NeXTSTEP epoch (https://developer.apple.com/documentation/foundation/nsdate/1409769-init) (2001-01-01T00:00:00Z, counting seconds using double-precision float point numbers.)
Sometimes it isn't possible to avoid them :(
In one incarnation I was developing soft realtime mobile phone charging systems. The tariff depended on the time of day/week/month/user and marketing whims. If the call is originated in Western Australia, terminated in the UK, and the billing system is in Canada, you have to be very careful which timezone you are meant to be using!
Epoch-ify the time at ingress. Define time periods always on UTC internally, you are set.
-
The Empire on which the sun never sets.
-
An interesting list: falsehoods programmers believe about time
http://infiniteundo.com/post/25509354022/more-falsehoods-programmers-believe-about-time (http://infiniteundo.com/post/25509354022/more-falsehoods-programmers-believe-about-time)