Don't Know Much About History

Stupid design is rampant in software, and with it stupid limitations. Inevitably someone wants our software to do $Action which isn't feasible due to design limitations. After receiving a negative answer to their question about whether something is possible, they turn into Veruca Salt:

"But why can't I do it?"
"Because we said so."
"But I waaaaant to."
"It won't work, but I'll file a New Feature Request for you."
"But I want to do it nooooowwww."
"Sorry."

Fighting with a software company is one thing, fighting with more than 100 years of historical standards and international treaties is another.

Hi,
We want to use UTC time so that all our times are synchronized but why do we have to use GMT as the base time zone? Since we're in Seattle we want all the times based on our own time zone. It should be possible to turn on UTC with a base time zone of Pacific time so how do we do it? This way the data in the database is still getting stamped with times relative to Seattle time and we do't have to do any calculation for our local jobs running here in Seattle.

Um... OK? So you don't understand how time zones work and that Seattle's time is itself based on UTC/GMT. If I were to write back and say that without further explanation I'd end up in a giant game of ping-pong in the usual "Why?"/"Because." pattern.

I decided to be helpful and explain things clearly.

The base time zone for UTC has to be GMT-0 because this is the designated "starting point" by international treaty. Initially decided at the 1884 International Meridian Conference (since 2/3 of all nautical charts used Greenwich as the prime meridian at the time), it was later codified around the world in 1958 with the beginning of International Atomic Time (TAI) and finalised in 1961.

Technically you could use Pacific time since some point has to be the starting point. Had the Nisqually "ruled the waves" in the late 19th century and come up with an extremely accurate naval chronograph, no one would care terribly much these days what time it was in some village seven miles outside London, and instead we might today say "Basin Mean Time". Alas, Britannia beat us to the punch.

As to the time stamps, they already are being stamped with a time relative to Seattle, a time exactly seven hours ahead of it (six during DST). Since your local jobs already run via scripting you only need to modify the scripts to be based on UTC for a locale nine hours behind. If a script should run at midnight, set it to run at a DB time of 4:00p.m.

Love, REC

And that should've been the end of it, but it never is.

I didn't ask for a history lesson, I asked for a solution. We need to use Pacific Time because our local database uses Pacific time and we don't feel we should have to change all our scripts. If we can't use Pacific time as our base time and won't synchronize our servers times and there's nothing more to say.

Yes, stamp around the room, hold your breath until you turn blue, get it out of your system. Words can't express how dreadfully upset I'll feel if your servers aren't synchronised.

This is my boilerplate response since so many different companies have sent in almost the exact same set of questions citing xthe exact same reasons. It's really uncanny. To date, two of them have ignored my explanation resulting in Prio-1 emergencies with serious data corruption, the fuckwits.

Endnote: I have a tenuous familial tie to the Nisqually and a direct familial tie to US DST codification; for two years of my youth DST was the center of discussion, interrupted only to inquire about a test in school that day or by admonitions to clean up that filthy, messy room of mine. It's ironic that as an adult -- as old now as my father was then -- I find myself knee-deep in DST issues, still receiving admonitions to clean up that filthy, messy roomdesk of mine.

x-posted from HuSi, where the Hanna-Barbera Survivor carnage continues.