I will never finish this time article

selected/time.md

@@ -82,7 +82,7 @@ Resources:
 
 ## Leap days and leap seconds
 
-Unfortunately, one year on the Gregorian calendar does not correspond exactly to one solar year. You're already well aware of how this is handled; every four years, February has an extra day. (Except for years divisible by 100, except for those which are also divisible by 400.) This is not very hard to handle, and it has no significant accuracy issues for the next millenium.
+Unfortunately, one year on the Gregorian calendar does not correspond exactly to one solar year. You're probably already aware of how this is handled; every four years, February has an extra day. (Except for years divisible by 100, except for those which are also divisible by 400.) This is not very hard to handle, and it will be accurate enough for at least the next 1000 years.
 
 Unfortunately, there is a more difficult problem - the Earth's rotation is somewhat irregular. A variety of geological effects can cause the Earth's rotation to speed up or slow down, causing a solar day to step out of sync with our clocks. In order to avoid this drift, _leap seconds_ are occasionally observed, extending or contracting the length of the day by one second. Unlike leap years, there is no set schedule for leap seconds - the Earth's rotation is not predictable enough. Computer systems must periodically download new timekeeping information so they always know of any upcoming leap seconds.
 
@@ -94,11 +94,11 @@ All of this has some consequences for programmers:
 - You probably should not assume that a minute has 60 seconds (because a leap second may make it 59 or 61).
 - 23:59:60 may be a valid time, depending on the day.
 
-The irregular and unpredictable nature of leap seconds has resulted in varying implementations. One common technique for dealing with leap seconds is essentially to ignore them: it is common for NTP servers to "smear" the leap second over a period of time, causing their clients to slowly drift until they match with real UTC again. In these cases, clients are completely unaware that a leap second is occurring. More information about leap smearing can be found in this article:
+The irregular and unpredictable nature of leap seconds has resulted in varying implementations. One common technique for dealing with leap seconds is essentially to ignore them: it is common for time synchronization servers to "smear" the leap second over a period of time, causing their clients to slowly drift until they match with real UTC again. In this case, clients are completely unaware that a leap second is occurring. More information about leap smearing can be found in this article:
 
 - https://docs.ntpsec.org/latest/leapsmear.html
 
-More on NTP later.
+[NOTE(ben): It kind of feels like we should have covered NTP in some limited way by now?]
 
 Resources:
 
@@ -106,11 +106,40 @@ Resources:
 - A site exploring the possibility of eliminating leap seconds by redefining a calendar day in UTC: https://www.ucolick.org/~sla/leapsecs/
 
 ## Date representations, the Unix epoch, and the year 2038 problem
+
+With all these concepts established, the question now is how to actually represent these in your application. For most uses of eeeboo beeboo
+
+- Unix timestamp
+  - Seconds since January 1, 1970 UTC
+  - Unambiguously stores an instant in time, but _nothing else_
+  - Somewhat ambiguous for dates before 1972 (because UTC was not established yet)
+  - Trivial computer representation (a single number)
+  - Not human readable
+- RFC 3339 date-time
+  - Unambiguously stores an instant in time
+  - Indicates offset from UTC (but _not_ time zone in the proper sense - no DST)
+  - Human-readable
+  - Restricted subset of ISO 8601
+    - You literally have no reason to use ISO 8601. Just don't. A copy of the spec costs hundreds of dollars, and it allows way more formats than anyone needs. Anyone who claims to accept "ISO 8601 timestamps" is wrong; they probably actually support RFC 3339 and a few variants. Meanwhile, RFC 3339 is freely available and has a small but complete set of features.
+  - Contains useful definitions for both date and time encoding
+  - 
+
+|                |      |      |
+| -------------- | ---- | ---- |
+| Unix timestamp |      |      |
+|                |      |      |
+|                |      |      |
+
+
+
     - RFC 3339 and its pitfalls
     - Other profiles (ISO8601)
     - IANA tzdb
-## How do I actually know what time it is
+
-    - NTP
+
+# What time is it actually: time synchronization
+    - NTP/chrony
+    - forkingpaths help you are the one who is the smart
 
 
 # How long things take: durations