README.zone_spec_csv_file 4.1 KB

1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889909192
  1. The csv file containing the zone_specs used by the
  2. boost::local_time::tz_database is intended to be customized by the
  3. library user. When customizing this file (or creating your own) the
  4. file must follow a specific format.
  5. This first line is expected to contain column headings and is therefore
  6. not processed by the tz_database.
  7. Each record (line) must have eleven fields. Some of those fields can
  8. be empty. Every field (even empty ones) must be enclosed in double-quotes.
  9. Ex:
  10. "America/Phoenix" <- string enclosed in quotes
  11. "" <- empty field
  12. Some fields represent a length of time. The format of these fields must be:
  13. "{+|-}hh:mm[:ss]" <- length-of-time format
  14. Where the plus or minus is mandatory and the seconds are optional.
  15. Since some time zones do not use daylight savings it is not always necessary
  16. for every field in a zone_spec to contain a value. All zone_specs must have
  17. at least ID and GMT offset. Zones that use daylight savings must have all
  18. fields filled except: STD ABBR, STD NAME, DST NAME. You should take note
  19. that DST ABBR is mandatory for zones that use daylight savings (see field
  20. descriptions for further details).
  21. ********* Fields and their description/details *********
  22. * ID
  23. Contains the identifying string for the zone_spec. Any string will
  24. do as long as it's unique. No two ID's can be the same.
  25. * STD ABBR
  26. * STD NAME
  27. * DST ABBR
  28. * DST NAME
  29. These four are all the names and abbreviations used by the time
  30. zone being described. While any string will do in these fields,
  31. care should be taken. These fields hold the strings that will be
  32. used in the output of many of the local_time classes.
  33. Ex:
  34. time_zone nyc = tz_db.time_zone_from_region("America/New_York");
  35. local_time ny_time(date(2004, Aug, 30), IS_DST, nyc);
  36. cout << ny_time.to_long_string() << endl;
  37. // 2004-Aug-30 00:00:00 Eastern Daylight Time
  38. cout << ny_time.to_short_string() << endl;
  39. // 2004-Aug-30 00:00:00 EDT
  40. NOTE: The exact format/function names may vary - see local_time
  41. documentation for further details.
  42. * GMT offset
  43. This is the number of hours added to utc to get the local time
  44. before any daylight savings adjustments are made. Some examples
  45. are: America/New_York offset -5 hours, & Africa/Cairo offset +2 hours.
  46. The format must follow the length-of-time format described above.
  47. * DST adjustment
  48. The amount of time added to gmt_offset when daylight savings is in
  49. effect. The format must follow the length-of-time format described
  50. above.
  51. #####################################################################
  52. ##### TODO: more rule capabilities are needed - this portion of #####
  53. ##### the tz_database is incomplete #####
  54. #####################################################################
  55. * DST Start Date rule
  56. This is a specially formatted string that describes the day of year
  57. in which the transition take place. It holds three fields of it's own,
  58. separated by semicolons.
  59. * The first field indicates the "nth" weekday of the month. The
  60. possible values are: 1 (first), 2 (second), 3 (third),
  61. 4 (fourth), 5 (fifth), and -1 (last).
  62. * The second field indicates the day-of-week from 0-6 (Sun=0).
  63. * The third field indicates the month from 1-12 (Jan=1).
  64. Examples are: "-1;5;9"="Last Friday of September",
  65. "2;1;3"="Second Monday of March"
  66. * Start time
  67. Start time is the number of hours past midnight, on the day of the
  68. start transition, the transition takes place. More simply put, the
  69. time of day the transition is made (in 24 hours format). The format
  70. must follow the length-of-time format described above with the
  71. exception that it must always be positive.
  72. * DST End date rule
  73. See DST Start date rule. The difference here is this is the day
  74. daylight savings ends (transition to STD).
  75. * End time
  76. Same as Start time.