Don't forget to account for general relativity. ![Banging Head |O](https://www.eevblog.com/forum/Smileys/default/bangheadonwall.gif.pagespeed.ce.8iLbFYV4Bc.gif)
... 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
![Smiley :)](https://www.eevblog.com/forum/Smileys/default/xsmiley.gif.pagespeed.ic.R8GFI-pF6f.png)
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.
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.
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 ![Smiley :)](https://www.eevblog.com/forum/Smileys/default/xsmiley.gif.pagespeed.ic.R8GFI-pF6f.png)
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 (2001-01-01T00:00:00Z, counting seconds using double-precision float point numbers.)
Maybe. Complicated and error prone, this time and calendar stuff ![Smiley :)](https://www.eevblog.com/forum/Smileys/default/xsmiley.gif.pagespeed.ic.R8GFI-pF6f.png)
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 (2001-01-01T00:00:00Z, counting seconds using double-precision float point numbers.)
Sometimes it isn't possible to avoid them
![Sad :(](https://www.eevblog.com/forum/Smileys/default/xsad.gif.pagespeed.ic.L3FGyzQrjB.png)
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 for billing, and you have to modify your date handling to match theirs
![Tongue :P](https://www.eevblog.com/forum/Smileys/default/xtongue.gif.pagespeed.ic.J5mTe0A2NA.png)
.
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 (2001-01-01T00:00:00Z, counting seconds using double-precision float point numbers.)
Sometimes it isn't possible to avoid them ![Sad :(](https://www.eevblog.com/forum/Smileys/default/xsad.gif.pagespeed.ic.L3FGyzQrjB.png)
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.