[SLUG] Re: Time Pedantry

2010-04-09 Thread Steve Allen
On Apr 8, 1:54 am, Jamie Wilkinson j...@spacepants.org wrote:
 I don't understand what you mean; TAI has been around since 1955.
 What is special about next month that we go back to 1955?

TAI can be extrapolated back to 1955, but it has only existed
since 1971, and for all practical purposes it was irrelevant to
any time stamp until 1972.

TAI is not defined for any instant until the publication of the
issue of BIPM Circular T that covers that instant.
Circular T is published monthly.  It is not possible to assert
the value of TAI now, only some approximation of TAI.  Only
BIPM can assert what is or is not TAI lest things get confused
as people start abusing phrases such as official TAI as made
distinct from something which is not TAI but which gets called TAI.
http://www.bipm.org/jsp/en/TimeFtp.jsp?TypePub=publication#TAIPubFormPubli2

  That exists and it's called zoneinfo and it gets updated all the
  time as a result of arbitrary and unpredictable human fiat.

 zoneinfo is for timezones, it doesn't convert between timescales.

At a technical level I don't see a substantive difference.
POSIX demands that zoneinfo handle offsets of seconds.
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html


Re: [SLUG] Re: Time Pedantry

2010-04-08 Thread Jamie Wilkinson
On 8 April 2010 12:39, Steve Allen sla29...@gmail.com wrote:


 On Apr 7, 7:03 pm, Jamie Wilkinson j...@spacepants.org wrote:
 If time_t was defined as a representation of TAI instead of UTC, it'd
 be harder to get it wrong.

 Except that TAI is not available until next month and the BIPM
 recommends against the use of TAI in any real-time system.

I don't understand what you mean; TAI has been around since 1955.
What is special about next month that we go back to 1955?  Will we
need more zoneinfo updates?


 Of course then you'd
 need a presentation layer to convert TAI into your local human
 calendar, but that's pretty simple once the model and view are
 separated

 That exists and it's called zoneinfo and it gets updated all the
 time as a result of arbitrary and unpredictable human fiat.

zoneinfo is for timezones, it doesn't convert between timescales.
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html


Re: [SLUG] Re: Time Pedantry

2010-04-08 Thread David Lloyd

Hmmm...

-Original Message-
From: Steve Allen sla29...@gmail.com
To: slug@slug.org.au
Subject: [SLUG] Re: Time Pedantry
Date: Wed, 7 Apr 2010 19:39:46 -0700 (PDT)



On Apr 7, 7:03 pm, Jamie Wilkinson j...@spacepants.org wrote:
 If time_t was defined as a representation of TAI instead of UTC, it'd
 be harder to get it wrong.

Except that TAI is not available until next month and the BIPM
recommends against the use of TAI in any real-time system.


When is next month again :?

DSL
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html


[SLUG] Re: Time Pedantry

2010-04-07 Thread Steve Allen
On Apr 6, 7:38 pm, Robert Collins robe...@robertcollins.net wrote:
 http://www.opengroup.org/onlinepubs/009695399/basedefs/time.h.html

 The range [0,60] seconds allows for positive or negative leap seconds.
 The formal definition of UTC does not permit double leap seconds, so all
 mention of double leap seconds has been removed, and the range shortened
 from the former [0,61] seconds seen in previous versions of POSIX.

but they still couldn't fix the Epoch Fail

http://www.ucolick.org/~sla/leapsecs/epochtime.html
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html


Re: [SLUG] Re: Time Pedantry

2010-04-07 Thread Glen Turner
On Wed, 2010-04-07 at 11:57 +1000, Jamie Wilkinson wrote:
 On 3 April 2010 12:51, Nick Andrew n...@nick-andrew.net wrote:
  Pity that unix time_t ignores leap seconds :-)
 
 And the corollary that anyone using ntpd or other time synchronisation
 discipline now has a gettimeofday() that breaks the POSIX definition.

The point of an operating system is to present a useful abstraction
of the hardware, including the time of day clock.  An abstraction
which includes all the arcana of timekeeping isn't actually that
useful for most applications.  time_t -- despite its shortcomings --
is a fine abstraction, so much so that most operating systems designed
since have stolen this abstraction rather than use a structure of
Y/M/D H:M:S as done by pre-UNIX operating systems.

If you do need to track the arcana then there are multiple abstractions
of increasing complexity, all of which are deficient for some users, all
of which are less and less useful to everyday applications.

Dissing time_t because it is so simple is to miss the point. It is a
good abstraction because it is simple and the majority of the
applications which use it wouldn't know or care what to do with a leap
second.

As for the specific point, there's nothing to stop difftime() applying
leap second adjustments.

-- 
 Glen Turner
 www.gdt.id.au/~gdt

-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html


Re: [SLUG] Re: Time Pedantry

2010-04-07 Thread Jamie Wilkinson
On 8 April 2010 10:56, Glen Turner g...@gdt.id.au wrote:
 On Wed, 2010-04-07 at 11:57 +1000, Jamie Wilkinson wrote:
 On 3 April 2010 12:51, Nick Andrew n...@nick-andrew.net wrote:
  Pity that unix time_t ignores leap seconds :-)

 And the corollary that anyone using ntpd or other time synchronisation
 discipline now has a gettimeofday() that breaks the POSIX definition.

 The point of an operating system is to present a useful abstraction
 of the hardware, including the time of day clock.  An abstraction
 which includes all the arcana of timekeeping isn't actually that
 useful for most applications.  time_t -- despite its shortcomings --
 is a fine abstraction, so much so that most operating systems designed
 since have stolen this abstraction rather than use a structure of
 Y/M/D H:M:S as done by pre-UNIX operating systems.

 If you do need to track the arcana then there are multiple abstractions
 of increasing complexity, all of which are deficient for some users, all
 of which are less and less useful to everyday applications.

 Dissing time_t because it is so simple is to miss the point. It is a
 good abstraction because it is simple and the majority of the
 applications which use it wouldn't know or care what to do with a leap
 second.

The problem I've seen in the wild is that time_t looks good enough
most of the time, but the arcana starts to matter in certain
applications at fine resolutions, when it gets stepped during
leapseconds (breaking monotonicity).  People using gettimeofday to
measure timing in their applications because it looks right get
surprised when time goes backwards for a moment and their logs are
wrong, programs crash, etc; when they really wanted to use
clock_gettime(CLOCK_MONOTONIC, ...) instead but just didn't know it;
the introduction of the article Daniel Pittman posted earlier
(http://naggum.no/lugm-time.html) sums the problem up as the impedance
mismatch between the mess that we call time, and the preciseness of
time as an orderly concept in science and a mess in the rest of human
existence

As an aside, the point I was making before about the POSIX definition
is that time_t is supposed to represent the number of seconds since
the start of the Unix epoch: midnight UTC of January 1, 1970; however
every time a leap second occurs, that timescale is reset.  It's
neither a monotonic clock nor a representation of UTC, but it
frequently gets confused for both (which isn't so bad, it looks like
UTC for the most part until we need to count a 61st second, but
there's out human calendaring bias appearing again).  Anything that
assumes monotonicity and stability in the calendar is at fault; but
for a specific example around time_t, any library using gettimeofday
to figure out what now is, and then offering to calculate time
offsets at seconds resolution over intervals of years needs to be
aware of that fact; no library I'm aware of does this.   Nobody cares
that they celebrated 1234567890 24 seconds too late.  (Hopefully
nobody cares about celebrating 1234567890? ;-)   People tend not to
care about that resolution at that interval; too much data, so what
does it matter anyway? (Aside aside: the perl calendaring libraries do
make an effort to do the right thing if you need to know the number of
days between now and before the Gregorian calendar started, which is
roughly the same concept on a coarser granularity of phase.)

If time_t was defined as a representation of TAI instead of UTC, it'd
be harder to get it wrong.  They're a good match; one's just a counter
and the other is a stable monotonic timescale.  Of course then you'd
need a presentation layer to convert TAI into your local human
calendar, but that's pretty simple once the model and view are
separated; TAI is very easy to define, the conversion from TAI to UTC
is welldefined, measuring time intervals from pairs of TAI dates is
simple arithmetic because of the guarantees of that timescale.
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html


[SLUG] Re: Time Pedantry

2010-04-07 Thread Steve Allen


On Apr 7, 7:03 pm, Jamie Wilkinson j...@spacepants.org wrote:
 If time_t was defined as a representation of TAI instead of UTC, it'd
 be harder to get it wrong.

Except that TAI is not available until next month and the BIPM
recommends against the use of TAI in any real-time system.

 Of course then you'd
 need a presentation layer to convert TAI into your local human
 calendar, but that's pretty simple once the model and view are
 separated

That exists and it's called zoneinfo and it gets updated all the
time as a result of arbitrary and unpredictable human fiat.
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html


Re: [SLUG] Re: Time Pedantry

2010-04-06 Thread Jamie Wilkinson
On 3 April 2010 12:51, Nick Andrew n...@nick-andrew.net wrote:
 On Fri, Apr 02, 2010 at 01:33:03PM +1100, Jake Anderson wrote:
 We should all just use unix timestamp for all date/time communications
 and be done with it.

 Pity that unix time_t ignores leap seconds :-)

And the corollary that anyone using ntpd or other time synchronisation
discipline now has a gettimeofday() that breaks the POSIX definition.



(I actually love that this thread came up.  Time is full of trivia and
holes and arcanity!)
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html


[SLUG] Re: Time Pedantry

2010-04-06 Thread Daniel Pittman
Jamie Wilkinson j...@spacepants.org writes:
 On 1 April 2010 16:56, Daniel Pittman dan...@rimspace.net wrote:
 Nick Andrew n...@nick-andrew.net writes:
 On Thu, Apr 01, 2010 at 03:39:00PM +1100, Daniel Pittman wrote:

 If it was my call, I would probably do the same thing.  Way too many
 developers get simple things like this day has no 2:30AM or this day has
 two 2:00AMs wrong.

 That's why Daylight Savings is fundamentally evil. Too much time data is
 stored in non-canonical formats.

 ...but the real question is if we love or hate the GMT/UTC difference, and
 23:59:61?

 *cough* :60 *cough*

Well, I am glad someone was on the ball enough to notice that. ;)

IIRC, :61 is actually a possible but extremely unlikely time value, to account
for two leap-second adjustments required in a year, but a quick look around
suggests that memory was wrong.  So, :60 it is.

[...]

 (And, finally, for anyone who really wants to despair at the whole thing,
  I give you The Long, Painful History of Time, which is the best write-up
  I know of about the engineering difficulties of the topic:
  http://naggum.no/lugm-time.html
  )

 I for one am glad such pages exist.  I wish the inventors of time_t had read
 it.

I wish that an awful lot of people had spent an awful lot more time looking at
what other systems around them were doing, so that I didn't have this terrible
feeling that we are finally dragging our system up to the 1980s for the second
or third time.

Ah, well.
Daniel
-- 
✣ Daniel Pittman✉ dan...@rimspace.net☎ +61 401 155 707
   ♽ made with 100 percent post-consumer electrons
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html


Re: [SLUG] Re: Time Pedantry

2010-04-06 Thread Robert Collins
On Wed, 2010-04-07 at 12:27 +1000, Daniel Pittman wrote:

  ...but the real question is if we love or hate the GMT/UTC difference, and
  23:59:61?
 
  *cough* :60 *cough*
 
 Well, I am glad someone was on the ball enough to notice that. ;)
 
 IIRC, :61 is actually a possible but extremely unlikely time value, to account
 for two leap-second adjustments required in a year, but a quick look around
 suggests that memory was wrong.  So, :60 it is.

http://www.opengroup.org/onlinepubs/009695399/basedefs/time.h.html

The range [0,60] seconds allows for positive or negative leap seconds.
The formal definition of UTC does not permit double leap seconds, so all
mention of double leap seconds has been removed, and the range shortened
from the former [0,61] seconds seen in previous versions of POSIX.


-Rob


signature.asc
Description: This is a digitally signed message part
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Re: Time Pedantry

2010-04-06 Thread Daniel Pittman
Robert Collins robe...@robertcollins.net writes:
 On Wed, 2010-04-07 at 12:27 +1000, Daniel Pittman wrote:

  ...but the real question is if we love or hate the GMT/UTC difference, and
  23:59:61?
 
  *cough* :60 *cough*
 
 Well, I am glad someone was on the ball enough to notice that. ;)
 
 IIRC, :61 is actually a possible but extremely unlikely time value, to 
 account
 for two leap-second adjustments required in a year, but a quick look around
 suggests that memory was wrong.  So, :60 it is.

 http://www.opengroup.org/onlinepubs/009695399/basedefs/time.h.html

 The range [0,60] seconds allows for positive or negative leap seconds.
 The formal definition of UTC does not permit double leap seconds, so all
 mention of double leap seconds has been removed, and the range shortened
 from the former [0,61] seconds seen in previous versions of POSIX.
 

Oh, /that/ was where it came from.  Thanks. :)
Daniel
-- 
✣ Daniel Pittman✉ dan...@rimspace.net☎ +61 401 155 707
   ♽ made with 100 percent post-consumer electrons
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html


Re: [SLUG] Re: Time Pedantry

2010-04-05 Thread Peter Rundle

Indeed. The Earth's rotational period does vary slightly (effect of
earthquakes notwithstanding). One reason time is hard to deal with
sensibly is our insistence on synchronising it to the mean solar day.


'Zactly! This time issue is easy to solve. ALL computers should be on UTC. All 
transactions should be stored in UTC.

Pilots have done it this way for years. When you get a weather forecast the times on it are stated in Zulu. (UTC). Then it doesnt' 
matter if you are taking off in Perth and flying to Sydney, or Darwin or if you are flying at the time Daylight savings changes 
over, Or indeed if you are leaving a country / state where daylight savings is changing and going to one that doesn't (e.g 
travelling from NSW into QLD at 15:30 UTC 3rd April). The time that the forecast was issued and the time period for which it is 
valid are unambiguous.


Local time is simply a presentation layer issue.

What time is it? It's 15:30 Zulu. It's up to the presentation layer to then ask the user what timezone they are in (or would 
like to see the value presented in) and to then convert the UTC value to the required timezone.


The fact that a Major National bank of a nation that spans a number of time zones, should store it's transactions in NSW local 
time zone is a indictment of poor design. Switching to using Linux wouldn't solve this problem, it's a symptom of poor system design.


Pete


--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html


Re: [SLUG] Re: Time Pedantry

2010-04-02 Thread Nick Andrew
On Fri, Apr 02, 2010 at 01:33:03PM +1100, Jake Anderson wrote:
 We should all just use unix timestamp for all date/time communications  
 and be done with it.

Pity that unix time_t ignores leap seconds :-)

Nick.
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html


[SLUG] Re: Time Pedantry

2010-04-01 Thread Daniel Pittman
Peter Hardy pe...@hardy.dropbear.id.au writes:
 On Thu, 2010-04-01 at 16:56 +1100, Daniel Pittman wrote:
 ...but the real question is if we love or hate the GMT/UTC difference, and
 23:59:61?

 Also, do we hate the earthquake that changed the length of the day for 
 messing
 with our time-keeping?
 http://www.sciencedaily.com/releases/2010/03/100302084522.htm

[...]

 None of this would be a problem if we'd just switch to decimal time in a
 single timezone and call it a day.

Actually, we would still have to deal with the changing length of the day, and
with the increasing difference between our stellar and earth-based times. :)

Daniel

-- 
✣ Daniel Pittman✉ dan...@rimspace.net☎ +61 401 155 707
   ♽ made with 100 percent post-consumer electrons
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html


Re: [SLUG] Re: Time Pedantry

2010-04-01 Thread Nick Andrew
On Thu, Apr 01, 2010 at 06:25:46PM +1100, Daniel Pittman wrote:
  None of this would be a problem if we'd just switch to decimal time in a
  single timezone and call it a day.
 
 Actually, we would still have to deal with the changing length of the day, and
 with the increasing difference between our stellar and earth-based times. :)

Indeed. The Earth's rotational period does vary slightly (effect of
earthquakes notwithstanding). One reason time is hard to deal with
sensibly is our insistence on synchronising it to the mean solar day.

Nick.
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html


Re: [SLUG] Re: Time Pedantry

2010-04-01 Thread Rick Welykochy

Nick Andrew wrote:


Indeed. The Earth's rotational period does vary slightly (effect of
earthquakes notwithstanding). One reason time is hard to deal with
sensibly is our insistence on synchronising it to the mean solar day.


// off topic Easter Time time ramblings

Isaac Asimov figured it out years ago. From memory ...

Create a new calendar with 52 weeks of 7 days = 364 days.
Add one extra day, called World Day, at the end - 365 days.
World Day does not have a day of the week. In this way,
every date falls on the same day of the week in every year.

For leaps years, add an extra Leap day after World Day. It too
has no day of the week. To make things precise, every 100 years,
there is no Leap Day, but every 400 years there is.

That pretty well matches up the solar year to the earth's rotation.

Easter Sunday would still be a lunar-based nightmare. Either that
or redefine it to fall on the same date always, or perhaps just
fall away completely.

I don't recall Asimov dealing with the tetchy problem of daylight
time.

As for rejigging the months? I leave that as as exercise.


cheers
rickw


--
_
Rick Welykochy || Praxis Services

Hofstadter's Law. It always takes longer than you expect, even when
you take into account Hofstadter's law.
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html


Re: [SLUG] Re: Time Pedantry

2010-04-01 Thread Daniel Pittman
Rick Welykochy r...@praxis.com.au writes:
 Nick Andrew wrote:

 Indeed. The Earth's rotational period does vary slightly (effect of
 earthquakes notwithstanding). One reason time is hard to deal with
 sensibly is our insistence on synchronising it to the mean solar day.

 // off topic Easter Time time ramblings
 Isaac Asimov figured it out years ago. From memory ...

 Create a new calendar with 52 weeks of 7 days = 364 days.  Add one extra
 day, called World Day, at the end - 365 days.  World Day does not have a day
 of the week. In this way, every date falls on the same day of the week in
 every year.

Note that this doesn't address the GMT/UT[C01] issue, which is all about the
relationship between local time and time-as-seen-by-astronomers, or perhaps
more clearly, time as it relates to the actions of things other than our own
planet rotating.

 For leaps years, add an extra Leap day after World Day. It too has no day of
 the week. To make things precise, every 100 years, there is no Leap Day, but
 every 400 years there is.

 That pretty well matches up the solar year to the earth's rotation.

I don't find this convincing, FWIW, since it doesn't address issues like
every five days in a terribly meaningful day.  All it does is translate
those into one of two problems:

Either you have every five days, except once a year when it is six or seven
days between instances, or every five days, but which day changes every
year.

Unfortunately, we can't just stop the world for world day, which means that we
still have unpredictable day/date matching.

[...]

 I don't recall Asimov dealing with the tetchy problem of daylight time.

IIRC he thought it was a silly idea, as were the politically motivated time
zones.  Both views are ... arguably true. :)

Daniel

-- 
✣ Daniel Pittman✉ dan...@rimspace.net☎ +61 401 155 707
   ♽ made with 100 percent post-consumer electrons
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html


Re: [SLUG] Re: Time Pedantry

2010-04-01 Thread Jake Anderson
We should all just use unix timestamp for all date/time communications 
and be done with it.


There I fixed it,
http://thereifixedit.files.wordpress.com/2010/03/129138460976317329.jpg
Hail me as leader

Daniel Pittman wrote:

Rick Welykochy r...@praxis.com.au writes:
  

Nick Andrew wrote:



Indeed. The Earth's rotational period does vary slightly (effect of
earthquakes notwithstanding). One reason time is hard to deal with
sensibly is our insistence on synchronising it to the mean solar day.
  

// off topic Easter Time time ramblings
Isaac Asimov figured it out years ago. From memory ...

Create a new calendar with 52 weeks of 7 days = 364 days.  Add one extra
day, called World Day, at the end - 365 days.  World Day does not have a day
of the week. In this way, every date falls on the same day of the week in
every year.



Note that this doesn't address the GMT/UT[C01] issue, which is all about the
relationship between local time and time-as-seen-by-astronomers, or perhaps
more clearly, time as it relates to the actions of things other than our own
planet rotating.

  

For leaps years, add an extra Leap day after World Day. It too has no day of
the week. To make things precise, every 100 years, there is no Leap Day, but
every 400 years there is.

That pretty well matches up the solar year to the earth's rotation.



I don't find this convincing, FWIW, since it doesn't address issues like
every five days in a terribly meaningful day.  All it does is translate
those into one of two problems:

Either you have every five days, except once a year when it is six or seven
days between instances, or every five days, but which day changes every
year.

Unfortunately, we can't just stop the world for world day, which means that we
still have unpredictable day/date matching.

[...]

  

I don't recall Asimov dealing with the tetchy problem of daylight time.



IIRC he thought it was a silly idea, as were the politically motivated time
zones.  Both views are ... arguably true. :)

Daniel

  


--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html


Re: [SLUG] Re: Time Pedantry

2010-04-01 Thread Rick Welykochy

Jake Anderson wrote:


We should all just use unix timestamp for all date/time communications
and be done with it.

There I fixed it,
http://thereifixedit.files.wordpress.com/2010/03/129138460976317329.jpg
Hail me as leader


Hey Leader,

Are the horses drawing a UTC cart clock or sumthink?

Happy Yeaster on 1270187886.
Is the next SLUG meeting at 1273927886?
CYA on 1271187886.


cheers
rickw



--
_
Rick Welykochy || Praxis Services

Hofstadter's Law. It always takes longer than you expect, even when
you take into account Hofstadter's law.
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html