How to compute Daylight/Summertime length?

49 views
Skip to first unread message

Susanne Meyer

unread,
Mar 20, 2016, 12:23:09 PM3/20/16
to cctz
Hi there,

Is there a method to compute the exact daylight/summer time length with or with help of cctz?

Today and in history there are/were non standard daylight/summer time shifts like half an hour 'LHDT - Lord Howe Daylight Time' or historical 'BDST - British Double Summer Time' and 'CEMT - Central Europe Midsummer Time' during World War II etc.

Currently I got to possible methods in mind to compute the length of summer time which I don't think are ideal:

1. Subtract the cctz utc offset from the standard time zone offset to get the summer time offset. Here I'm not sure where to get the standard time zone offset. And don't know if a standard timezone offset of a given time zone ever change or changed over time?

2. Scan the ouput time zone abbreviation of cctz for non standard summer time abbreviations. In case of LHDT, BDST, CEMT set the summer time length to its specific amount. The problem here is that I might not be aware of all non standard time zone abbreviations that exist.

Is there a more save and reliable method?

Susan

Bradley White

unread,
Mar 20, 2016, 3:07:39 PM3/20/16
to Susanne Meyer, CCTZ
On Sun, Mar 20, 2016 at 12:23 PM, 'Susanne Meyer' via cctz <cc...@googlegroups.com> wrote:
Hi there,

Hi Susanne,
 
Is there a method to compute the exact daylight/summer time length with or with help of cctz?

First allow me to clarify that, from the rest of your message, it appears that you mean how much the civil time changes during a DST shift.  For example, in the United States this spring the civil time jumped forward one hour.

CCTZ does not support anything like the standard (or daylight) offset for a TimeZone---a value like that changes over time.  You can, however, find the UTC offset (in "seconds east") applicable at a particular time_point, tp, in a TimeZone, tz, with ...

  int offset = BreakTime(tp, tz).offset;

So, if you had time_points on either side of a shift you could compute the size of the shift by taking the difference between their offsets.  (The Breakdown.is_dst field can tell you which offset is considered "non-standard".)

All that said, the question I have to ask at this stage is "what are you really trying to do?"  We generally discourage doing anything with offsets (or their differences).  Indeed the "offset" and "is_dst" fields come with a warning of imprudence.

Bradley

Susanne Meyer

unread,
Mar 20, 2016, 7:30:55 PM3/20/16
to cctz, b...@acm.org
Hi Bradley,

you wrote:
"
It appears that you mean how much the civil time changes during a DST shift"

Yes exactly - it is a value of 1h, 0.5h or 2h (standard, half or double daylight savings time) I'm searching for.

Do you know if the tz database time zones (for example 'America/Chicago) ever changed their standard UTC-Offset excluding DST (in any) like they are listed in Wikipedia? If the utc-offsets are fixed ('America/Chicago' = -6h) than it would be easy to calculate the searched value (bold written):

'cctz UTC-Offset' (full utc-offset incl. DST) - 'tz UTC-Offset' (standard utc-offset without DST) = 0.5, 1 or 2 h

Do you think this solution is reliable?

I'm aware that most likely nobody else will need this value, so I don't bother that cctz didn't support it directly. For computation I don't use this value neither. Its in a field in a standardized file exchange format (which I have to take as it is). I like to support it in my astronomical application, which can show the heaven in a single moment in time.

Susan

Bradley White

unread,
Mar 21, 2016, 2:16:47 PM3/21/16
to Susanne Meyer, CCTZ
On Sun, Mar 20, 2016 at 7:30 PM, 'Susanne Meyer' via cctz <cc...@googlegroups.com> wrote:
Do you know if the tz database time zones (for example 'America/Chicago) ever changed their standard UTC-Offset excluding DST (in any) like they are listed in Wikipedia? If the utc-offsets are fixed ('America/Chicago' = -6h) than it would be easy to calculate the searched value (bold written):

"America/Chicago" has been at a standard offset of -06:00 since "The Day of Two Noons" on Sunday, November 18, 1883.

I'm aware that most likely nobody else will need this value, so I don't bother that cctz didn't support it directly. For computation I don't use this value neither. Its in a field in a standardized file exchange format (which I have to take as it is). I like to support it in my astronomical application, which can show the heaven in a single moment in time.

I'm not an astronomer, and I don't know anything about your exchange format, but "a single moment in time" sounds like a time-zone-independent concept.  To display a star field you would need such an instant plus a geo location.  From the geo location you could select a time zone and so display a local civil time, but the UTC offset is secondary.

Bradley

Susanne Meyer

unread,
Mar 22, 2016, 8:57:13 AM3/22/16
to cctz, b...@acm.org
Hi Bradley,


you wrote:
"America/Chicago" has been at a standard offset of -06:00 since "The Day of Two Noons" on Sunday, November 18, 1883."

That was about the time when standard timezones in general were established. I think I have to learn more on tz timezones to get a more clear understanding. Because its not directly cctz related its off topic anyway.

Thank you very much for your help and your tolerance with my poor english language.

Susan

Reply all
Reply to author
Forward
0 new messages