[PLUG] odd date command behavior for the starting Daylight time in a year

Paul Munday paulm at freegeek.org
Thu Sep 26 11:58:21 PDT 2013


On Thu, 2013-09-26 at 10:54 -0700, Daniel Hedlund wrote:
> On Wed, Sep 25, 2013 at 10:54 PM, Dale Snell <ddsnell at frontier.com> wrote:
> 
> > Those March days are all Daylight Saving Time switchover days, aren't
> > they?  (If they're not, I'm going to look really stupid...)  There is
> > no 2:00AM hour on those days, thus the dates really are invalid.
> >
> 
> Dale is correct here in that they really aren't valid dates due to the
> daylight savings change.  To compound the problem, dates between 01:00:00
> and 01:59:59 are ambiguous if you don't specify a timezone.

I have a side project that deals with historic time data over multiple
timezones, and its tricky to say the least, even with libraries to do
the heavy lifting. Its kind of a notoriously tricky area where naive
solutions can go very wrong. It's an interesting subject. Further
reading  below if anyone is interested, I would particularly recommend A
literary appreciation of the Olson/Zoneinfo/tz database.

Paul M

Further Reading:
===========================================================

(from the python timezone library documentation)
In cases where countries change their timezone definitions, cases like
the end-of-daylight-savings-time occur with no way of resolving the
ambiguity. For example, in 1915 Warsaw switched from Warsaw time to
Central European time. So at the stroke of midnight on August 5th 1915
the clocks were wound back 24 minutes creating an ambiguous time period
that cannot be specified without referring to the timezone abbreviation
or the actual UTC offset. In this case midnight happened twice, neither
time during a daylight savings time period

http://pytz.sourceforge.net/

(from the gnu manual on date and time)

First, a quote:

Our units of temporal measurement, from seconds on up to months, are so
complicated, asymmetrical and disjunctive so as to make coherent mental
reckoning in time all but impossible. Indeed, had some tyrannical god
contrived to enslave our minds to time, to make it all but impossible
for us to escape subjection to sodden routines and unpleasant surprises,
he could hardly have done better than handing down our present system.
It is like a set of trapezoidal building blocks, with no vertical or
horizontal surfaces, like a language in which the simplest thought
demands ornate constructions, useless particles and lengthy
circumlocutions. Unlike the more successful patterns of language and
science, which enable us to face experience boldly or at least
level-headedly, our system of temporal calculation silently and
persistently encourages our terror of time. ...

It is as though architects had to measure length in feet, width in
meters and height in ells; as though basic instruction manuals demanded
a knowledge of five different languages. It is no wonder then that we
often look into our own immediate past or future, last Tuesday or a week
from Sunday, with feelings of helpless confusion. ... 

—Robert Grudin, Time and the Art of Living. 

https://www.gnu.org/software/coreutils/manual/html_node/Date-input-formats.html#Date-input-formats

http://blog.jonudell.net/2009/10/23/a-literary-appreciation-of-the-olsonzoneinfotz-database/
http://www.quirksmode.org/blog/archives/2009/04/making_time_saf.html
http://naggum.no/lugm-time.html
http://stackoverflow.com/questions/6841333/why-is-subtracting-these-two-times-in-1927-giving-a-strange-result/6841479#6841479




-- 
               Technical Support Specialist, Free Geek
              Free Geek Tech Support: support at freegeek.org
        (503) 232-9350 option 6 Tuesday-Saturday: 12-1,1:30-5:45PM




More information about the PLUG mailing list