Opened 12 years ago

Last modified 7 years ago

#605 assigned Feature Requests (None)

Support different DST rules in timezone db based on years

Reported by: nobody Owned by: az_sw_dude
Milestone: Component: date_time
Version: None Severity: Problem
Keywords: Cc:


The boost time library supports processing of the
timezone database file as a .csv, with one entry per
time zone, such as "America/New_York".  However, in
2007, the daylight savings time rules will change.  The
contents of the csv need to change, to incorporate a
range of effective years.  Since DST is a spring and
fall event (in both north and south hemispheres) only a
year need be recorded.

I suggest adding two values at the beginning of the
line, (as one field in the form nnnn-nnnn) for the low
effective-year and high effective-year, as 4-digit
values.  Let 0000 be used for "all previous years" and
9999 be used for all subsequent years.  [If the '-'
separator is a problem, ':' could be used instead.]

Then, the change in 2007 can be recorded as two lines:
"2007-9999","America/New_York", ...
"0000-2006","America/New_York", ...

Lines unaffected by the change would have "0000-9999"
as the first field.

Attachments (0)

Change History (4)

comment:1 Changed 12 years ago by quatras

Logged In: YES 

It might be easier, in terms of sorting the .csv file, to
combine the effective year range with the zone name, such as: 

    "America/New_York:0000-2006", ...

This would have the advantage of (a) keeping all entries for
the same zone together, (b) not adding a new column to the
table, and (c) not impacting time zones whose rules do not

comment:2 Changed 12 years ago by quatras

Logged In: YES 

After further thought, I believe a better way to do would be
to add a code at the end of the ID string that identifies
where the timezone is located, in general terms, so that a
secondary table can be checked for year ranges.  This has
the advantage of requiring only one entry instead of
multiples.  In the New York example, the string would become
"America/New_York;US".  The lookup routines would have to
stop the comparison at the ';'.  Then, the "US" value would
be used to look up US rules for the year in question.  I
would call the string "US" a 'group' code, to be followed by
a 'region' code.  For example, Hawaii has no DST; its code
could be ";US/HI".  The European Union has common DST
handling, so the string for Paris would be
"Europe/Paris;EU/FR".  The other major 'group' is Canada.  A
sample timezone file with these values is attached.

comment:3 Changed 10 years ago by Daryle Walker

Component: Nonedate_time
Severity: Problem

comment:4 Changed 7 years ago by Katie Chan

Summary: support new 2007 DST rules for timezone dbSupport different DST rules in timezone db based on years
Type: Support RequestsFeature Requests

Modify Ticket

Change Properties
Set your email in Preferences
as assigned The owner will remain az_sw_dude.

Add Comment

E-mail address and name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.