datetime - Daylight saving time and time zone best practices -

i hoping make question , answers definitive guide dealing daylight saving time, in particular dealing actual change overs.

if have add, please do

many systems dependent on keeping accurate time, problem changes time due daylight savings - moving clock forward or backwards.

for instance, 1 has business rules in order taking system depend on time of order - if clock changes, rules might not clear. how should time of order persisted? there of course endless number of scenarios - 1 illustrative one.

• how have dealt daylight saving issue?
• what assumptions part of solution? (looking context here)

as important, if not more so:

• what did try did not work?
• why did not work?

i interested in programming, os, data persistence , other pertinent aspects of issue.

general answers great, see details if available on 1 platform.

---

summary of answers , other data: (please add yours)

do:

• whenever referring exact moment in time, persist time according unified standard not affected daylight savings. (gmt , utc equivalent regard, preferred use term utc. notice utc known zulu or z time.)
• if instead choose persist time using local time value, include local time offset utc, such timestamp can later interpreted unambiguously.
• in cases, may need store both utc time , equivalent local time. done 2 separate fields, platforms support datetimeoffset type can store both in single field.
• when storing timestamps numeric value, use unix time - number of whole seconds since 1970-01-01t00:00:00z (excluding leap seconds). if require higher precision, use milliseconds instead. value should based on utc, without time zone adjustment.
• if might later need modify timestamp, include original time zone id can determine if offset may have changed original value recorded.
• when scheduling future events, local time preferred instead of utc, common offset change. see answer, , blog post.
• when storing whole dates, such birthdays , anniversaries, not convert utc or other time zone.
  • when possible, store in date-only data type not include time of day.
  • if such type not available, sure ignore time-of-day when interpreting value. if cannot assured time-of-day ignored, choose 12:00 noon, rather 00:00 midnight more safe representative time on day.
• remember time zone offsets not integer number of hours (for example, indian standard time utc+05:30, , nepal uses utc+05:45).
• if using java, use java.time java 8, or use joda time java 7 or lower.
• if using .net, consider using noda time.
• if using .net without noda time, consider datetimeoffset better choice datetime.
• if using perl, use datetime.
• if using python, use pytz or dateutil.
• if using javascript, use moment.js moment-timezone extension.
• if using php > 5.2, use native time zones conversions provided datetime, , datetimezone classes. careful when using datetimezone::listabbreviations() - see answer. keep php date olson data, install periodically the timezonedb pecl package; see answer.
• if using c++, sure use library uses implements iana timezone database. these include cctz, icu, , howard hinnant's "tz" library.
  • do not use boost time zone conversions. while its api claims support standard iana (aka "zoneinfo") identifiers, crudely maps them posix-style data, without considering rich history of changes each zone may have had. (also, file has fallen out of maintenance.)
• most business rules use civil time, rather utc or gmt. therefore, plan convert utc timestamps local time zone before applying application logic.
• remember time zones , offsets not fixed , may change. instance, historically , uk used same dates 'spring forward' , 'fall back'. however, in 2007 changed dates clocks changed on. means 48 weeks of year difference between london time , new york time 5 hours , 4 weeks (3 in spring, 1 in autumn) 4 hours. aware of items in calculations involve multiple zones.
• consider type of time (actual event time, broadcast time, relative time, historical time, recurring time) elements (timestamp, time zone offset , time zone name) need store correct retrieval - see "types of time" in this answer.
• keep os, database , application tzdata files in sync, between , rest of world.
• on servers, set hardware clocks , os clocks utc rather local time zone.
• regardless of previous bullet point, server-side code, including web sites, should never expect local time zone of server in particular. see answer.
• prefer working time zones on case-by-case basis in application code, rather globally through config file settings or defaults.
• use ntp services on servers.
• if using fat32, remember timestamps stored in local time, not utc.
• when dealing recurring events (weekly tv show, example), remember time changes dst , different across time zones.
• always query date-time values lower-bound inclusive, upper-bound exclusive (>=, <).

don't:

• do not confuse "time zone", such america/new_york "time zone offset", such -05:00. 2 different things. see the timezone tag wiki.
• do not use javascript's date object perform date , time calculations in older web browsers, ecmascript 5.1 , lower has a design flaw may use daylight saving time incorrectly. (this fixed in ecmascript 6 / 2015).
• never trust client's clock. may incorrect.
• don't tell people "always use utc everywhere". widespread advice shortsighted of several valid scenarios described earlier in document. instead, use appropriate time reference data working with. (timestamping can use utc, future time scheduling , date-only values should not.)

testing:

• when testing, make sure test countries in western, eastern, northern , southern hemispheres (in fact in each quarter of globe, 4 regions), both dst in progress , not (gives 8), , country not use dst (another 4 cover regions, making 12 in total).
• test transition of dst, i.e. when in summer time, select time value winter.
• test boundary cases, such timezone utc+12, dst, making local time utc+13 in summer , places utc+13 in winter
• test third-party libraries , applications , make sure handle time zone data correctly.
• test half-hour time zones, @ least.

reference:

• the detailed timezone tag wiki page on stack overflow
• olson database, aka tz_database
• ietf draft procedures maintaining olson database
• sources time zone , dst
• iso format (iso 8601)
• mapping between olson database , windows time zone ids, unicode consortium
• time zone page on wikipedia
• stackoverflow questions tagged dst
• stackoverflow questions tagged timezone
• dealing dst - microsoft datetime best practices
• network time protocol on wikipedia

other:

• lobby representative end abomination dst. can hope...
• lobby earth standard time