Skip to content
Snippets Groups Projects
  1. Feb 05, 2016
  2. Oct 03, 2015
  3. May 16, 2015
  4. Jan 31, 2015
  5. Dec 24, 2014
    • Tom Lane's avatar
      Add CST (China Standard Time) to our lists of timezone abbreviations. · 5c866589
      Tom Lane authored
      For some reason this seems to have been missed when the lists in
      src/timezone/tznames/ were first constructed.  We can't put it in Default
      because of the conflict with US CST, but we should certainly list it among
      the alternative entries in Asia.txt.  (I checked for other oversights, but
      all the other abbreviations that are in current use according to the IANA
      files seem to be accounted for.)  Noted while responding to bug #12326.
      5c866589
  6. Nov 17, 2014
  7. Oct 16, 2014
    • Tom Lane's avatar
      Support timezone abbreviations that sometimes change. · 7c67b936
      Tom Lane authored
      Up to now, PG has assumed that any given timezone abbreviation (such as
      "EDT") represents a constant GMT offset in the usage of any particular
      region; we had a way to configure what that offset was, but not for it
      to be changeable over time.  But, as with most things horological, this
      view of the world is too simplistic: there are numerous regions that have
      at one time or another switched to a different GMT offset but kept using
      the same timezone abbreviation.  Almost the entire Russian Federation did
      that a few years ago, and later this month they're going to do it again.
      And there are similar examples all over the world.
      
      To cope with this, invent the notion of a "dynamic timezone abbreviation",
      which is one that is referenced to a particular underlying timezone
      (as defined in the IANA timezone database) and means whatever it currently
      means in that zone.  For zones that use or have used daylight-savings time,
      the standard and DST abbreviations continue to have the property that you
      can specify standard or DST time and get that time offset whether or not
      DST was theoretically in effect at the time.  However, the abbreviations
      mean what they meant at the time in question (or most recently before that
      time) rather than being absolutely fixed.
      
      The standard abbreviation-list files have been changed to use this behavior
      for abbreviations that have actually varied in meaning since 1970.  The
      old simple-numeric definitions are kept for abbreviations that have not
      changed, since they are a bit faster to resolve.
      
      While this is clearly a new feature, it seems necessary to back-patch it
      into all active branches, because otherwise use of Russian zone
      abbreviations is going to become even more problematic than it already was.
      This change supersedes the changes in commit 513d06de et al to modify the
      fixed meanings of the Russian abbreviations; since we've not shipped that
      yet, this will avoid an undesirably incompatible (not to mention incorrect)
      change in behavior for timestamps between 2011 and 2014.
      
      This patch makes some cosmetic changes in ecpglib to keep its usage of
      datetime lookup tables as similar as possible to the backend code, but
      doesn't do anything about the increasingly obsolete set of timezone
      abbreviation definitions that are hard-wired into ecpglib.  Whatever we
      do about that will likely not be appropriate material for back-patching.
      Also, a potential free() of a garbage pointer after an out-of-memory
      failure in ecpglib has been fixed.
      
      This patch also fixes pre-existing bugs in DetermineTimeZoneOffset() that
      caused it to produce unexpected results near a timezone transition, if
      both the "before" and "after" states are marked as standard time.  We'd
      only ever thought about or tested transitions between standard and DST
      time, but that's not what's happening when a zone simply redefines their
      base GMT offset.
      
      In passing, update the SGML documentation to refer to the Olson/zoneinfo/
      zic timezone database as the "IANA" database, since it's now being
      maintained under the auspices of IANA.
      7c67b936
  8. Oct 04, 2014
    • Tom Lane's avatar
      Update time zone data files to tzdata release 2014h. · 8f75d7a2
      Tom Lane authored
      Most zones in the Russian Federation are subtracting one or two hours
      as of 2014-10-26.  Update the meanings of the abbreviations IRKT, KRAT,
      MAGT, MSK, NOVT, OMST, SAKT, VLAT, YAKT, YEKT to match.
      
      The IANA timezone database has adopted abbreviations of the form AxST/AxDT
      for all Australian time zones, reflecting what they believe to be current
      majority practice Down Under.  These names do not conflict with usage
      elsewhere (other than ACST for Acre Summer Time, which has been in disuse
      since 1994).  Accordingly, adopt these names into our "Default" timezone
      abbreviation set.  The "Australia" abbreviation set now contains only
      CST,EAST,EST,SAST,SAT,WST, all of which are thought to be mostly historical
      usage.  Note that SAST has also been changed to be South Africa Standard
      Time in the "Default" abbreviation set.
      
      Add zone abbreviations SRET (Asia/Srednekolymsk) and XJT (Asia/Urumqi),
      and use WSST/WSDT for western Samoa.
      
      Also a DST law change in the Turks & Caicos Islands (America/Grand_Turk),
      and numerous corrections for historical time zone data.
      8f75d7a2
  9. Oct 03, 2014
    • Tom Lane's avatar
      Update time zone abbreviations lists. · d7d546bb
      Tom Lane authored
      This updates known_abbrevs.txt to be what it should have been already,
      were my -P patch not broken; and updates some tznames/ entries that
      missed getting any love in previous timezone data updates because zic
      failed to flag the change of abbreviation.
      
      The non-cosmetic updates:
      
      * Remove references to "ADT" as "Arabia Daylight Time", an abbreviation
      that's been out of use since 2007; therefore, claiming there is a conflict
      with "Atlantic Daylight Time" doesn't seem especially helpful.  (We have
      left obsolete entries in the files when they didn't conflict with anything,
      but that seems like a different situation.)
      
      * Fix entirely incorrect GMT offsets for CKT (Cook Islands), FJT, FJST
      (Fiji); we didn't even have them on the proper side of the date line.
      (Seems to have been aboriginal errors in our tznames data; there's no
      evidence anything actually changed recently.)
      
      * FKST (Falkland Islands Summer Time) is now used all year round, so
      don't mark it as a DST abbreviation.
      
      * Update SAKT (Sakhalin) to mean GMT+11 not GMT+10.
      
      In cosmetic changes, I fixed a bunch of wrong (or at least obsolete)
      claims about abbreviations not being present in the zic files, and
      tried to be consistent about how obsolete abbreviations are labeled.
      
      Note the underlying timezone/data files are still at release 2014e;
      this is just trying to get us in sync with what those files actually
      say before we go to the next update.
      d7d546bb
  10. Jul 22, 2014
    • Tom Lane's avatar
      Reject out-of-range numeric timezone specifications. · f54d97c5
      Tom Lane authored
      In commit 631dc390, we started to handle
      simple numeric timezone offsets via the zic library instead of the old
      CTimeZone/HasCTZSet kluge.  However, we overlooked the fact that the zic
      code will reject UTC offsets exceeding a week (which seems a bit arbitrary,
      but not because it's too tight ...).  This led to possibly setting
      session_timezone to NULL, which results in crashes in most timezone-related
      operations as of 9.4, and crashes in a small number of places even before
      that.  So check for NULL return from pg_tzset_offset() and report an
      appropriate error message.  Per bug #11014 from Duncan Gillis.
      
      Back-patch to all supported branches, like the previous patch.
      (Unfortunately, as of today that no longer includes 8.4.)
      f54d97c5
  11. Jul 19, 2014
  12. May 06, 2014
    • Bruce Momjian's avatar
      Remove tabs after spaces in C comments · 0b44914c
      Bruce Momjian authored
      This was not changed in HEAD, but will be done later as part of a
      pgindent run.  Future pgindent runs will also do this.
      
      Report by Tom Lane
      
      Backpatch through all supported branches, but not HEAD
      0b44914c
  13. Mar 15, 2014
  14. Feb 17, 2014
    • Tom Lane's avatar
      Prevent potential overruns of fixed-size buffers. · 655b665f
      Tom Lane authored
      Coverity identified a number of places in which it couldn't prove that a
      string being copied into a fixed-size buffer would fit.  We believe that
      most, perhaps all of these are in fact safe, or are copying data that is
      coming from a trusted source so that any overrun is not really a security
      issue.  Nonetheless it seems prudent to forestall any risk by using
      strlcpy() and similar functions.
      
      Fixes by Peter Eisentraut and Jozef Mlich based on Coverity reports.
      
      In addition, fix a potential null-pointer-dereference crash in
      contrib/chkpass.  The crypt(3) function is defined to return NULL on
      failure, but chkpass.c didn't check for that before using the result.
      The main practical case in which this could be an issue is if libc is
      configured to refuse to execute unapproved hashing algorithms (e.g.,
      "FIPS mode").  This ideally should've been a separate commit, but
      since it touches code adjacent to one of the buffer overrun changes,
      I included it in this commit to avoid last-minute merge issues.
      This issue was reported by Honza Horak.
      
      Security: CVE-2014-0065 for buffer overruns, CVE-2014-0066 for crypt()
      655b665f
  15. Feb 15, 2014
    • Tom Lane's avatar
      8f46ea7d
    • Tom Lane's avatar
      Update time zone data files to tzdata release 2013i. · 4f975b68
      Tom Lane authored
      DST law changes in Jordan; historical changes in Cuba.
      
      Also, remove the zones Asia/Riyadh87, Asia/Riyadh88, and Asia/Riyadh89.
      Per the upstream announcement:
          The files solar87, solar88, and solar89 are no longer distributed.
          They were a negative experiment -- that is, a demonstration that
          tz data can represent solar time only with some difficulty and error.
          Their presence in the distribution caused confusion, as Riyadh
          civil time was generally not solar time in those years.
      4f975b68
  16. Dec 01, 2013
  17. Nov 01, 2013
    • Tom Lane's avatar
      Fix some odd behaviors when using a SQL-style simple GMT offset timezone. · 2e213495
      Tom Lane authored
      Formerly, when using a SQL-spec timezone setting with a fixed GMT offset
      (called a "brute force" timezone in the code), the session_timezone
      variable was not updated to match the nominal timezone; rather, all code
      was expected to ignore session_timezone if HasCTZSet was true.  This is
      of course obviously fragile, though a search of the code finds only
      timeofday() failing to honor the rule.  A bigger problem was that
      DetermineTimeZoneOffset() supposed that if its pg_tz parameter was
      pointer-equal to session_timezone, then HasCTZSet should override the
      parameter.  This would cause datetime input containing an explicit zone
      name to be treated as referencing the brute-force zone instead, if the
      zone name happened to match the session timezone that had prevailed
      before installing the brute-force zone setting (as reported in bug #8572).
      The same malady could affect AT TIME ZONE operators.
      
      To fix, set up session_timezone so that it matches the brute-force zone
      specification, which we can do using the POSIX timezone definition syntax
      "<abbrev>offset", and get rid of the bogus lookaside check in
      DetermineTimeZoneOffset().  Aside from fixing the erroneous behavior in
      datetime parsing and AT TIME ZONE, this will cause the timeofday() function
      to print its result in the user-requested time zone rather than some
      previously-set zone.  It might also affect results in third-party
      extensions, if there are any that make use of session_timezone without
      considering HasCTZSet, but in all cases the new behavior should be saner
      than before.
      
      Back-patch to all supported branches.
      2e213495
  18. Sep 02, 2013
  19. Mar 28, 2013
  20. Mar 24, 2013
    • Tom Lane's avatar
      Update time zone abbreviation lists for changes missed since 2006. · 3a003c5a
      Tom Lane authored
      Most (all?) of Russia has moved to what's effectively year-round daylight
      savings time, so that the "standard" zone names now mean an hour later
      than they used to.  Update that, notably changing MSK as per recent
      complaint from Sergey Konoplev, but also CHOT, GET, IRKT, KGT, KRAT,
      MAGT, NOVT, OMST, VLAT, YAKT, YEKT.  The corresponding DST abbreviations
      are presumably now obsolete, but I left them in place with their old
      definitions, just to reduce any possible breakage from this change.
      
      Also add VOLT (Europe/Volgograd), which for some reason we never had
      before, as well as MIST (Antarctica/Macquarie), and fix obsolete
      definitions of MAWT, TKT, and WST.
      3a003c5a
  21. Jan 14, 2013
    • Tom Lane's avatar
      Add new timezone abbrevation "FET". · 7938d84a
      Tom Lane authored
      This seems to have been invented in 2011 to represent GMT+3, non daylight
      savings rules, as now used in Europe/Kaliningrad and Europe/Minsk.
      There are no conflicts so might as well add it to the Default list.
      Per bug #7804 from Ruslan Izmaylov.
      7938d84a
  22. Dec 02, 2012
  23. Sep 19, 2012
  24. Aug 14, 2012
    • Tom Lane's avatar
      Update time zone data files to tzdata release 2012e. · dabbd3ee
      Tom Lane authored
      DST law changes in Morocco; Tokelau has relocated to the other side of
      the International Date Line; and apparently Olson had Tokelau's GMT
      offset wrong by an hour even before that.
      
      There are also a large number of non-significant changes in this update.
      Upstream took the opportunity to remove trailing whitespace, and the
      SCCS-style version numbers on the individual files are gone too.
      dabbd3ee
  25. Jun 10, 2012
  26. May 31, 2012
  27. Apr 25, 2012
    • Tom Lane's avatar
      Fix edge-case behavior of pg_next_dst_boundary(). · c62b8eaa
      Tom Lane authored
      Due to rather sloppy thinking (on my part, I'm afraid) about the
      appropriate behavior for boundary conditions, pg_next_dst_boundary() gave
      undefined, platform-dependent results when the input time is exactly the
      last recorded DST transition time for the specified time zone, as a result
      of fetching values one past the end of its data arrays.
      
      Change its specification to be that it always finds the next DST boundary
      *after* the input time, and adjust code to match that.  The sole existing
      caller, DetermineTimeZoneOffset, doesn't actually care about this
      distinction, since it always uses a probe time earlier than the instant
      that it does care about.  So it seemed best to me to change the API to make
      the result=1 and result=0 cases more consistent, specifically to ensure
      that the "before" outputs always describe the state at the given time,
      rather than hacking the code to obey the previous API comment exactly.
      
      Per bug #6605 from Sergey Burladyan.  Back-patch to all supported versions.
      c62b8eaa
  28. Apr 24, 2012
  29. Jan 02, 2012
  30. Nov 30, 2011
  31. Oct 28, 2011
  32. Sep 09, 2011
    • Tom Lane's avatar
      Simplify handling of the timezone GUC by making initdb choose the default. · ca4af308
      Tom Lane authored
      We were doing some amazingly complicated things in order to avoid running
      the very expensive identify_system_timezone() procedure during GUC
      initialization.  But there is an obvious fix for that, which is to do it
      once during initdb and have initdb install the system-specific default into
      postgresql.conf, as it already does for most other GUC variables that need
      system-environment-dependent defaults.  This means that the timezone (and
      log_timezone) settings no longer have any magic behavior in the server.
      Per discussion.
      ca4af308
  33. Sep 05, 2011
  34. Aug 23, 2011
  35. Jul 26, 2011
  36. Jun 09, 2011
  37. May 12, 2011
    • Tom Lane's avatar
      Split PGC_S_DEFAULT into two values, for true boot_val vs computed default. · e05b8664
      Tom Lane authored
      Failure to distinguish these cases is the real cause behind the recent
      reports of Windows builds crashing on 'infinity'::timestamp, which was
      directly due to failure to establish a value of timezone_abbreviations
      in postmaster child processes.  The postmaster had the desired value,
      but write_one_nondefault_variable() didn't transmit it to backends.
      
      To fix that, invent a new value PGC_S_DYNAMIC_DEFAULT, and be sure to use
      that or PGC_S_ENV_VAR (as appropriate) for "default" settings that are
      computed during initialization.  (We need both because there's at least
      one variable that could receive a value from either source.)
      
      This commit also fixes ProcessConfigFile's failure to restore the correct
      default value for certain GUC variables if they are set in postgresql.conf
      and then removed/commented out of the file.  We have to recompute and
      reinstall the value for any GUC variable that could have received a value
      from PGC_S_DYNAMIC_DEFAULT or PGC_S_ENV_VAR sources, and there were a
      number of oversights.  (That whole thing is a crock that needs to be
      redesigned, but not today.)
      
      However, I intentionally didn't make it work "exactly right" for the cases
      of timezone and log_timezone.  The exactly right behavior would involve
      running select_default_timezone, which we'd have to do independently in
      each postgres process, causing the whole database to become entirely
      unresponsive for as much as several seconds.  That didn't seem like a good
      idea, especially since the variable's removal from postgresql.conf might be
      just an accidental edit.  Instead the behavior is to adopt the previously
      active setting as if it were default.
      
      Note that this patch creates an ABI break for extensions that use any of
      the PGC_S_XXX constants; they'll need to be recompiled.
      e05b8664
  38. Apr 25, 2011
Loading