The document discusses various perspectives and assumptions related to working with dates and times. It explains that dates and times can be viewed differently depending on location and time zone. Common assumptions around dates and times, such as the number of hours in a day or that time zone offsets never change, are problematic. The document emphasizes considering multiple perspectives, distinguishing between local and absolute time, accounting for time zone changes, using quality libraries, and avoiding assumptions when working with dates and times.

1. DATE ANDTIME
Odds, Ends, and Oddities

2. About Me
www.maggiepint.com
@maggiepint
maggiepint@gmail.com
https://www.tempworks.com

3. https://xkcd.com/1597/

4. Like Git:
• Date and time is complicated
• At first, we avoid learning date and time
But also, like Git:
• Date and time makes sense
• Date and time can be fun

5. 5 O'clock Somewhere

6. PERSPECTIVE
We all see dates and times from different angles

7. The GlobalTimeline
1 2 3 4 5 6 7 8 9
Point in absolute time

8. Coordinated UniversalTime (UTC)
• A perspective of the global timeline
• Allows us to keep track of absolute time
• Primary standard by which the world regulates clocks
• Defined precisely by scientific community
• Includes leap seconds
• Has no relationship to geography
• Basically the same as GMT, but GMT is not defined precisely by the scientific
community

9. LocalTime
• A local time is a perspective of time
• It does not represent a point on the global timeline
• It is usually not a contiguous timeline (DST)

10. UTC Time:
2016-04-09T14:17:47Z
What we know
• The point in absolute time
• Whether this time is before or after
another point in time
What we don’t know
• Whether it is morning or night
• What day of the week it is

11. LocalTime:
Saturday,April 9, 2016 9:11 AM
We Know
• It is Saturday
• It is morning
We Don’t Know
• What point this is on the global
timeline
• Whether it is before or after a time
from a different locality
• What the time will be if we add one
hour to this time

12. TIME ZONES
Uniting Perspectives

13. Time Zone Basics
• A time zone is a region that observes a uniform standard time
• A time zone is defined by a set of offsets from UTC
• Offsets are typically in one hour intervals, but not always
• Nepal StandardTime is UTC +5:45
• Time zones frequently have multiple offsets
• There are two main resources for time zones
• Internet Assigned Numbers Authority (IANA)
• WindowsTime Zones
• IANA time zones are more widely used, and more accurate

14. Time Zone: America/Chicago

15. Politics
• Time zones are inherently political
• Governments change time zones regularly
• Governments change time zones suddenly
• Russia this year is an example of politicians causing time chaos
• http://bit.ly/1SB9TvW
• Morocco reverts to standard time during Ramadan
• Assume nothing

16. IANATime Zone Libraries
• JavaScript - MomentTimeZone
• http://momentjs.com/timezone/
• .NET – NodaTime
• http://nodatime.org/
• Java 8 + - java.time (native)
• Java 7 - JodaTime
• See Stack Overflow post for more exhaustive list
• http://bit.ly/1RUYuuM

17. Time Zones are not Offsets!
"2016-04-09T19:39:00-05:00“
This date could be in:
• America/Chicago
• America/Bahia_Banderas
• America/Bogata
• America/Cancun
• America/Cayman
• And more

18. ASSUMPTIONS
Things we think we know

19. Assumption
“If you just store everything in UTC, all your
problems will be solved.”

20. ATableWith Everything in UTC

21. Show me all the messages for the
business day of April 4th.
I have users in London, and across the United States.
In LondonApril 4th is between 2016-04-03 23:00:00Z and 2016-04-04 22:59:59Z
In MinneapolisApril 4th is between 2016-04-04 05:00:00Z and 2016-04-05 04:59:59Z

22. Perspectives
• When storing a date, consider the following perspectives
• Absolute time
• Time local to the date’s viewer
• Time local to the date’s originator

23. 2016-04-09T20:18:48-05:00
ISO 8601 Format with Offset
Local Date LocalTime Offset

24. Why use ISO 8601 format?
• With offset, reflects both local and absolute perspective
• Has unambiguous ordering
• Compare this to 4/10/2016
• In the US this is April 10th
• In the UK this is October 4th
• Helps avoid having to compute local perspective from absolute
during querying
• Supported by nearly all modern databases
• Databases will automatically order in absolute time

25. Assumption
“If I just store everything in ISO 8601 with an
offset, everything will be fine.”

26. Future Dates
• Time zones change over time
• In the future, the offset of a scheduled time could change
• Store future dates in local time with a time zone

27. Assumption
“There are 24 hours in a day, and 365 days in a
year.”

28. moment('2016-03-12 12:00').add(1, 'day').format('LLL')
"March 13, 2016 12:00 PM"
moment('2016-03-12 12:00').add(24,'hour').format('LLL')
"March 13, 2016 1:00 PM"

29. moment('2016-02-28').add(365, 'days').format('LLL')
"February 27, 2017 12:00 AM"
moment('2016-02-28').add(1, 'year').format('LLL')
"February 28, 2017 12:00 AM"

30. As Seen on Stack Overflow
var startHours = 8;
var startMinutes = 30;
var ed = new Date();
var endHours = ed.getHours();
var endMinutes = ed.getMinutes();
var elapsedMinutes = (endHours * 60 + endMinutes) - (startHours * 60 +
startMinutes);
console.log(elapsedMinutes);

31. Assumption
“Time and date math work in the same way.”

32. moment('2016-01-01').add(1.5, 'hours').format('LLL')
"January 1, 2016 1:30AM“
moment('2016-01-01').add(1.5, 'days').format('LLL')
"January 3, 2016 12:00 AM"

33. Time Math vs Date Math
Time math:
• Refers to operations involving hours, minutes, seconds, milliseconds
• Works by incrementing or decrementing the position on the global timeline by the number of
units in question
• Can use fractional units
Date Math:
• Refers to all operations larger than hours – days, months, years, quarters, etc.
• Works by moving places on the calendar
• Cannot be converted to time math
• Cannot use fractional units

34. Assumption
“All dates and times exist once in all time
zones”

35. moment('2016-10-16').format('LLL')
October 16, 2016 1:00 AM

36. Spring Forward in JavaScript

37. Fall Back in JavaScript

38. Assumption
“The Date object in JavaScript works.”

39. var a = new Date('2016-01-01');
a.toString();
"Thu Dec 31 2015 18:00:00 GMT-0600 (Central StandardTime)"
var a = new Date('1/1/2016');
a.toString();
"Fri Jan 01 2016 00:00:00 GMT-0600 (Central StandardTime)"

40. Known JavaScript Date Issues
• DSTTransitions can go both directions
• Months index from zero
• No support for time zones other than user’s local time zone and UTC
• Older browsers know only current DST rules
• Parsing is implementation specific and basically completely broken
• The spec is a disaster
http://codeofmatt.com/2013/06/07/javascript-date-type-is-
horribly-broken/

41. IN SUMMARY
We all know what happens when you assume

42. CONSIDER ALL PERSPECTIVES

43. DISTINGUISH BETWEEN LOCAL AND
ABSOLUTETIME

44. REMEMBER,TIME ZONES CHANGE
RAPIDLY

45. STORE FUTURE DATES IN LOCALTIME

46. DISTINGUISH BETWEEN DATE MATH
ANDTIME MATH

47. DON’TTRUST JAVASCRIPT DATE

48. USE A QUALITY LIBRARY

49. MAKE NO ASSUMPTIONS

50. Be like this guy:

51. Additional Resources
• Date andTime Fundamentals – Matt Johnson, Pluralsight
• https://www.pluralsight.com/courses/date-time-fundamentals
• Matt Johnson’s Blog
• http://codeofmatt.com/
• LauTaarnskov’s Blog
• http://www.creativedeletion.com/
• NodaTime’s Documentation
• http://nodatime.org/
• Time Programming Fundamentals – Greg Miller CPPCon 2015
• http://bit.ly/1SgO3E0
• Moment.js
• http://momentjs.com/

52. About Me
www.maggiepint.com
@maggiepint
maggiepint@gmail.com
https://github.com/maggiepint
https://www.tempworks.com