Daylight Saving Shift

[Roedy Green]

Daylight saving shift back happened 2AM this 2009-11-01.

For tips on handling DST in Java and in the OS, see
http://mindprod.com/jgloss/dst.html

Check out the links.

 

[Joshua Cranmer]

Daylight saving shift back happened 2AM this 2009-11-01.

Only if you live in Canada or the US.

In Australia, the shift forward happened about 28 days ago, and it
happened in New Zealand the week before (I think).
In Europe, the shift back happened last week.
In myriads of other countries, the change happens not at all or at other
times.

In short: March, April, September, and October are hell for scheduling
meetings as you try to decide who is on DST and who is not.

Also, while I do appreciate your attempts to remind us of important
yearly chronological headaches, keep in mind that approximately 95% of
the world does not live in the US or Canada and thus does not follow the
same DST rules.

 

[Arved Sandstrom]

Only if you live in Canada or the US.

In Australia, the shift forward happened about 28 days ago, and it
happened in New Zealand the week before (I think).
In Europe, the shift back happened last week.
In myriads of other countries, the change happens not at all or at other
times.

In short: March, April, September, and October are hell for scheduling
meetings as you try to decide who is on DST and who is not.

[ SNIP ]

Makes you wonder why one even needs to (I acknowledge that these days a
person does still need to, more often than not.) After all, when a
meeting is set up for a given date it's understood to be at a certain
time for a certain participant in a certain location. When that
participant says 2 PM he means 2 PM regardless, and you'd think that in
2009 software finally could have solved these date/time problems. After
all, it's not like the problem is exactly an extremely difficult one,
although it seems to have taken on that mantle. I think it's more a
commentary on the state of programming rather than on the intrinsic
difficulty of the problem that we still have these issues.

AHS

 

[Joshua Cranmer]

When that
participant says 2 PM he means 2 PM regardless, and you'd think that in
2009 software finally could have solved these date/time problems.

Say a meeting (via telephone, not face-to-face) takes place at 9 AM
Pacific, 5 PM British time on a recurring basis. Is the time coordinated
to UTC (therefore doesn't change during DST, you have to account for it
manually), coordinated to the US Pacific time, or is it coordinated to
the British time? Throw in another dozen localities and suddenly
publishing the local times for every participant is a nightmare.

Plus you have the messy business of trying to remember twice a year
whether or not you have to change your clocks back an hour or forward an
hour. Spring back, fall forward or fall back, spring forward? They both
sound correct to me...

 

[Arved Sandstrom]

Say a meeting (via telephone, not face-to-face) takes place at 9 AM
Pacific, 5 PM British time on a recurring basis. Is the time coordinated
to UTC (therefore doesn't change during DST, you have to account for it
manually), coordinated to the US Pacific time, or is it coordinated to
the British time? Throw in another dozen localities and suddenly
publishing the local times for every participant is a nightmare.

My point was, you can always pin a meeting time to a datetime in *one*
given location. Phrasing it as a 9 AM Pacific *and* 5 PM British is
already a cause of problems - just phrase it as 5 PM British *or* 9 AM
Pacific, and let the other parties worry about the translation.

I myself don't understand why this gets people so twisted. I've had to
deal with plenty of phone conferences, webexes, etc etc with
participants from the West Coast through the East Coast through the
Atlantic provinces through to Europe, and it hasn't usually caused major
problems if people do proper translations.

It doesn't have to be a nightmare - that's the whole thing. If someone
says that the proposed meeting time is 3 PM local on Oct 28th of this
year, tied to Dublin, I refuse to believe that folks in the other
timezones can't locate some decent software that tells them when that is
in their spot in their local time. The actual rules for working this
stuff out are not that complicated, although lots of software developers
certainly seem to find them so.

Plus you have the messy business of trying to remember twice a year
whether or not you have to change your clocks back an hour or forward an
hour. Spring back, fall forward or fall back, spring forward? They both
sound correct to me...

Just as for the rules for magnetic declination, I don't even try to
remember any of that. It's easy enough to work out from first principles
and local knowledge. For example, if you know that DST is intended to
give you more hours of light in the evening, that immediately tells you
in what direction the clock must go.

AHS

 

[Lew]

Daylight saving shift back happened 2AM this 2009-11-01.

Not everywhere.

 

[Lew]

Just as for the rules for magnetic declination, I don't even try to
remember any of that. It's easy enough to work out from first principles
and local knowledge. For example, if you know that DST is intended to
give you more hours of light in the evening, that immediately tells you
in what direction the clock must go.

The irony is that Daylight Savings does not give you more hours of light in
the evening. It just makes people go to (and thus leave) work an hour
earlier. The evening itself still has the same number of hours of light.

 

[Alan Morgan]

Only if you live in Canada or the US.

And then only if you don't live in Hawaii or Arizona (unless you
live in the Navajo Nation, in which case you do). The situation
in Indiana used to be *completely* insane, but it has now been
revised to be merely annoying.

All in favor of OST (Obama Standard Time), please raise your hands.

Alan

 

[Donkey Hottie]

1.11.2009 16:09, Joshua Cranmer kirjoitti:

Plus you have the messy business of trying to remember twice a year
whether or not you have to change your clocks back an hour or forward an
hour. Spring back, fall forward or fall back, spring forward? They both
sound correct to me...

Rule of thumb: always towards the nearest summer.

 

[Martin Gregorie]

Daylight saving shift back happened 2AM this 2009-11-01.

Not anywhere I've lived, apart from a year in NYC. OTOH, I've only
resided in countries that use DST but I've never seen the point. I'd
rather keep the clocks fixed and, if anything should be changed, change
business and school, etc. hours.

The most people-friendly arrangement I've met was the one India used in
the late 70s: since winter days are shorter than summer days, business
hours were adjusted accordingly: IIRC winter opening times were about two
hours less than summer hours.

 

[Arne Vajhøj]

Makes you wonder why one even needs to (I acknowledge that these days a
person does still need to, more often than not.) After all, when a
meeting is set up for a given date it's understood to be at a certain
time for a certain participant in a certain location. When that
participant says 2 PM he means 2 PM regardless, and you'd think that in
2009 software finally could have solved these date/time problems. After
all, it's not like the problem is exactly an extremely difficult one,
although it seems to have taken on that mantle. I think it's more a
commentary on the state of programming rather than on the intrinsic
difficulty of the problem that we still have these issues.

Yes.

But it is a problem.

I don't know what Outlook does, but it does not always work well for
a reoccurring meeting scheduled over DST changes.

Arne

 

[Arne Vajhøj]

The irony is that Daylight Savings does not give you more hours of light
in the evening. It just makes people go to (and thus leave) work an
hour earlier. The evening itself still has the same number of hours of
light.

Not if the evening starts when you are home from work.

Arne

 

[Roedy Green]

2009 software finally could have solved these date/time problems.

The catch is every program that deals with time needs to be aware of
the shifts. Java handles most of the problem in class libraries, but
you still have the problem of data input, given that 2009-11-01 2:01
is not a unique identifier of a time instant. Most programs just
ignore the problem or use standard time.

DST is not going away. Perhaps we could use it all year. That would
get rid of the shifts which are the major bugbear.

I see no advantage in losing an hour of evening daylight in November.

Maybe we will see DST creep till it totally takes over.

The other possibility, at least for Internet communication, email and
international meetups is to use UTC.

 

[Arne Vajhøj]

The catch is every program that deals with time needs to be aware of
the shifts. Java handles most of the problem in class libraries, but
you still have the problem of data input, given that 2009-11-01 2:01
is not a unique identifier of a time instant.

There should be an isAmbiguous method somewhere in a class.

Most programs just
ignore the problem or use standard time.

I don't think so. Such a program would be rather tricky to write.

DST is not going away. Perhaps we could use it all year. That would
get rid of the shifts which are the major bugbear.

I see no advantage in losing an hour of evening daylight in November.

Maybe we will see DST creep till it totally takes over.

The politicians make that decision.

We just need to write the software to match those decisions.

Note that even if DST changes were completely removed, then we
would still need to support it due to historical data.

Arne

 

[Lew]

Not if the evening starts when you are home from work.

Then when the evening starts depends on what job you do. A farmer's evening
starts at full dark by that definition.

Doesn't it make more sense to define evening in terms of where the sun is than
what one's profession is?

I define evening as when the sun is close to setting, i.e., when the light
begins to fade. It's a fuzzy concept, of course, but utterly not dependent on
what the clock says.

I define afternoon as when sun passes its zenith.

I find other definitions stupid, as indeed I find the whole concept of
Daylight Savings Time. Ptui! I spit on the practice!

 

[Lew]

The politicians make that decision.

We just need to write the software to match those decisions.

Note that even if DST changes were completely removed, then we
would still need to support it due to historical data.

I would favor abolishing DST altogether. If that means leaving the clock set
ahead of historic Standard Time settings, so be it, although the last time
that was tried in the U.S. (in the 1970s) it was a failure. People objected
to the children having to wait for morning school buses in the dark, among
other things.

The subject is politically controversial. Some claim energy savings due to
the use of DST. AFAIK there's no hard evidence to support this, at least, not
that takes into account the increase in costs due to air conditioning and
morning lighting. Certainly there are lots of claims that DST saves energy,
but for some reason no one ever seems to cite studies or methodologies to
support those claims. There is a vocal but politically disadvantaged
contingent that denies the validity of those claims.

But our infinitely wise and benevolent governments say that it must be so,
though somehow jurisdictions that don't use DST don't seem to suffer unduly
thereby. As Arne points out, dates are a matter of socio-political mandate
and our software simply must reflect the reality.

 

[Joshua Cranmer]

The subject is politically controversial. Some claim energy savings due
to the use of DST. AFAIK there's no hard evidence to support this, at
least, not that takes into account the increase in costs due to air
conditioning and morning lighting. Certainly there are lots of claims
that DST saves energy, but for some reason no one ever seems to cite
studies or methodologies to support those claims. There is a vocal but
politically disadvantaged contingent that denies the validity of those
claims.

The recent research summaries I've seen all seem to indicate that the
impact of DST on energy use is somewhere around ±0.2% (it's a number
that's rarely put into full context, so I'm not exactly sure what the
percentage is of--probably average daily summer energy usage). The sign
is naturally hotly debated in political circles whenever tweaking DST is
bandied about.

*Performs some searching to find research papers*

The literature review I just finished reading seems to suggest that most
of the conclusions about the energy-saving nature of DST were formulated
about 25 years ago, when lighting in particular was much less efficient
than now (the hypothetical best-case scenario for energy savings would
be equivalent to replacing about 15% of your incandescent light bulbs
with compact fluorescents) and also fails to take into account the
modern shifts in habits. Its primary conclusion was "the stuff out there
sucks, we need modern comprehensive research on this topic."

Other papers recently published seem to suggest that DST may no longer
be saving energy. That may just be a manifestation of confirmation or
perhaps publication bias--I'd expect that people finding energy savings
due to DST would be less likely to publish their results nowadays. I'm
also not a big fan of DST myself.

Oh well, if humanity ever discovers interplanetary or even interstellar
travel (as well as sufficiently speedy communication to make
chronological synchronization across disparate settlements necessary),
the mess resulting from DST will be the least of our worries.

 

[Morris Keesan]

Historically it is the other way round: DST is a special time shift
applied during summer. Thus, DST does not remove an hour of evening
daylight in November; rather, it adds an hour of evening daylight in
March.

Rather, it removes an hour of morning daylight in March, which doesn't get
restored until November.

 

[Lew]

Rather, it removes an hour of morning daylight in March, which doesn't get
restored until November.

It does neither for me. I just get up "later" and stay up "later" by the
clock during DST. I find the longer summer days do plenty to add both morning
and afternoon daylight during that season.

Since I'm required to get to work an hour earlier (by the sun) during DST, I
get more tardiness lectures from the bosses in the summer than the winter.

I've read that the clock changes produce increased health problems, but I have
no idea how valid that assertion is.

 

[Wojtek]

Roedy Green wrote :

Daylight saving shift back happened 2AM this 2009-11-01.

Not in Saskatchewan it didn't