Astrology

Posted Sep 29, 2021 9:12 UTC (Wed) by nim-nim (subscriber, #34454)
In reply to: Astrology by tialaramex
Parent article: A fork for the time-zone database?

Accurate timing of past events is not just a matter for astrology.

For example, if you wanted to analyze past electricity use to design future “smart”, “green” or whatever power grids, you‘d better make sure your past DST info is right as when people go to work or return home changes the whole distribution pattern, (so much that’s why DST was invented in the first place).

More so if you want to cross-check data around areas with different time history.

Astrology

Posted Sep 29, 2021 11:37 UTC (Wed) by bluca (subscriber, #118303) [Link] (2 responses)

Is data before 1970 really useful for that purpose?

Astrology

Posted Sep 29, 2021 14:53 UTC (Wed) by nim-nim (subscriber, #34454) [Link] (1 responses)

For infrastructure projects, it’s not as if one could procure data somewhere else than in the past. Time moves a lot slower for anything that involves masses of steel and concrete at country level. You extrapolate from historical data because as imperfect as it is it’s way better than pure guesswork.

Astrology

Posted Sep 29, 2021 14:55 UTC (Wed) by nim-nim (subscriber, #34454) [Link]

(also it is very common to re-analyze historical data with new models to check their accuracy).

Astrology

Posted Oct 10, 2021 7:53 UTC (Sun) by ssmith32 (subscriber, #72404) [Link] (2 responses)

It's tangential, but shouldn't you be normalizing everything into UTC for such purposes?

People will still be arriving and leaving at the same time, just in one timezone, which seems much easier to reason about, from the perspective of a grid that crosses multiple zones.

Also, while the buildings don't change that fast, I imagine usage varies wildly from pre-1970 patterns... And large commercial buildings (e.g. skyscrapers) older than 1970? How many of those really exist?

Astrology

Posted Oct 10, 2021 18:12 UTC (Sun) by Wol (subscriber, #4433) [Link] (1 responses)

> It's tangential, but shouldn't you be normalizing everything into UTC for such purposes?

Why? Einstein said all time is relative, don't make one zone absolute. It was bad enough when Magellan went round the world and couldn't understand why everybody else was a day wrong in their calendar. What are the space station astronauts going to when they come home after 6 months and their UTC isn't the same as everyone else's?

MOST people don't have anything to do with timezones. MOST people have difficulty (including programmers) dealing with timezones.

As per Einstein time depends on the observer. And how many systems do you know, with historic time data, that have no concept of time zone? Most of them? The ONLY special time zone is the one you're in. And it's only special because YOU ARE THE OBSERVER.

Just define time as being 24 hours a day, clock time as the time from the preceding midnight OF INTEREST (so a night shift can quite happily end AFTER midnight eg 30:00 hours), and a full unambiguous spec is "local time T zulu offset" with NO guarantee that local time is less than 24:00 or that zulu offset lies between -12:00 and +12:00. The ONLY thing you guarantee is that if you normalise time, the day will move to correct time to the *expected* 24 hours. And on request time zone will normalise to zulu.

Cheers,
Wol

Normalizing on UTC

Posted Oct 20, 2021 14:07 UTC (Wed) by 1kay (subscriber, #154880) [Link]

In my experience, normalizing local time (data given by humans) to UTC is one of the important uses of the TZ database.