<story><title>Dates and Times in JavaScript – A New API for Dates from TC39</title><url>https://blogs.igalia.com/compilers/2020/06/23/dates-and-times-in-javascript/</url></story><parent_chain><item><author>WorldMaker</author><text>Almost everything should be capable of parsing and outputting ISO 8601 dates [1] today. About the biggest recommendation that still seems to lacking in documentation is that you should probably consider offsets (Z or -0500 etc) required rather than &amp;quot;optional&amp;quot;, and that you have to remember that offsets are not timezones (and that generally you should store offsets as presented rather than convert between offsets; makes it easier to adjust offsets based on timezones).&lt;p&gt;[1] &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;en.wikipedia.org&amp;#x2F;wiki&amp;#x2F;ISO_8601&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;en.wikipedia.org&amp;#x2F;wiki&amp;#x2F;ISO_8601&lt;/a&gt;</text></item><item><author>lmkg</author><text>Basically we need Unicode But For Time.&lt;p&gt;These are similar problems: getting a computer-amenable model of something that&amp;#x27;s fundamentally a &lt;i&gt;human&lt;/i&gt; phenomenon, and carries multiple centuries and multiple continents of accumulated context, ambiguity, and edge-cases. This is an extremely difficult class of problems, but in the case of text &amp;amp; characters, we managed to finally get a pretty well-functioning and broadly-supported solution after a few decades of gratuitously-incompatible half-solutions. There&amp;#x27;s hope.</text></item><item><author>tzs</author><text>I&amp;#x27;d like to see the JavaScript people, the Java people, the PHP people, the Perl people, the Python people, the C people, the C++ people, and the people for every other significant language that supports functions (either directly or as methods on objects) to get together and once and for all agree on how the heck we are supposed to deal with times and dates.&lt;p&gt;Then all of them should implement that in their standard library, so that going forward we&amp;#x27;ve got one sane conceptual time handling system everywhere.&lt;p&gt;I tire of dealing with the quirks of everyone having their own approach.</text></item></parent_chain><comment><author>sratner</author><text>&amp;gt; consider offsets (Z or -0500 etc) required rather than &amp;quot;optional&amp;quot;&lt;p&gt;ISO8601 without an offset is semantically different to one with an offset, it represents a time in local timezone (context-dependent). It isn&amp;#x27;t an &amp;quot;optional&amp;quot; offset in the sense that you can just omit it, it is a fundamentally different data type.&lt;p&gt;Without this distinction, there is no way to specify a local time in ISO8601, which would be highly inconvenient for certain applications. For example, how do you represent an event that occurs at 9am every day &lt;i&gt;regardless of location&lt;/i&gt;? After all, dates and times are used for more than just storing absolute timestamps.&lt;p&gt;You are absolutely correct that offsets are also not timezones, which makes the ability to specify local &amp;quot;floating&amp;quot; times even more important (i.e. you can&amp;#x27;t just denormalize the above concept into a list of timestamps with offsets for each timezone you care about, as the offsets will change over time [edit: and tz-&amp;gt;offset conversion is lossy and not reversible]).</text></comment>
<story><title>Dates and Times in JavaScript – A New API for Dates from TC39</title><url>https://blogs.igalia.com/compilers/2020/06/23/dates-and-times-in-javascript/</url></story><parent_chain><item><author>WorldMaker</author><text>Almost everything should be capable of parsing and outputting ISO 8601 dates [1] today. About the biggest recommendation that still seems to lacking in documentation is that you should probably consider offsets (Z or -0500 etc) required rather than &amp;quot;optional&amp;quot;, and that you have to remember that offsets are not timezones (and that generally you should store offsets as presented rather than convert between offsets; makes it easier to adjust offsets based on timezones).&lt;p&gt;[1] &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;en.wikipedia.org&amp;#x2F;wiki&amp;#x2F;ISO_8601&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;en.wikipedia.org&amp;#x2F;wiki&amp;#x2F;ISO_8601&lt;/a&gt;</text></item><item><author>lmkg</author><text>Basically we need Unicode But For Time.&lt;p&gt;These are similar problems: getting a computer-amenable model of something that&amp;#x27;s fundamentally a &lt;i&gt;human&lt;/i&gt; phenomenon, and carries multiple centuries and multiple continents of accumulated context, ambiguity, and edge-cases. This is an extremely difficult class of problems, but in the case of text &amp;amp; characters, we managed to finally get a pretty well-functioning and broadly-supported solution after a few decades of gratuitously-incompatible half-solutions. There&amp;#x27;s hope.</text></item><item><author>tzs</author><text>I&amp;#x27;d like to see the JavaScript people, the Java people, the PHP people, the Perl people, the Python people, the C people, the C++ people, and the people for every other significant language that supports functions (either directly or as methods on objects) to get together and once and for all agree on how the heck we are supposed to deal with times and dates.&lt;p&gt;Then all of them should implement that in their standard library, so that going forward we&amp;#x27;ve got one sane conceptual time handling system everywhere.&lt;p&gt;I tire of dealing with the quirks of everyone having their own approach.</text></item></parent_chain><comment><author>riquito</author><text>Not every point in time refers to a timezone.
If I write that 1 january 1970 was an eventful date, I can&amp;#x27;t&amp;#x2F;dont want to add a timezone to it. Then you may want to store&amp;#x2F;format times without dates, etc...</text></comment>