<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
	<channel>
		<title>Iso 8601 on vxlabs</title>
		<link>https://vxlabs.com/tags/iso-8601/</link>
		<description>Recent content in Iso 8601 on vxlabs</description>
		<generator>Hugo</generator>
		<language>en-us</language>
		
		
		
		
			<lastBuildDate>Tue, 15 Oct 2024 19:39:40 +0200</lastBuildDate>
		
			<atom:link href="https://vxlabs.com/tags/iso-8601/index.xml" rel="self" type="application/rss+xml" />
			<item>
				<title>PySpark timezone offset from ISO 8601 without UDF</title>
				<link>https://vxlabs.com/2024/10/15/pyspark-timezone-offset-from-iso-8601-without-udf/</link>
				<pubDate>Tue, 15 Oct 2024 19:39:40 +0200</pubDate>
				<guid>https://vxlabs.com/2024/10/15/pyspark-timezone-offset-from-iso-8601-without-udf/</guid>
				<description>&lt;h2 id=&#34;background&#34;&gt;Background&lt;/h2&gt;&#xA;&lt;p&gt;During my work at &lt;a href=&#34;https://stonethree.com/&#34;&gt;Stone Three&lt;/a&gt; upgrading some of our data pipelines with &lt;a href=&#34;https://azure.microsoft.com/en-us/products/databricks&#34;&gt;Azure DataBricks&lt;/a&gt;, I was quite disappointed to learn that Spark 3.5.3&amp;rsquo;s only timezone-capable timestamp type &lt;a href=&#34;https://community.databricks.com/t5/technical-blog/introducing-timestamp-ntz-in-apache-spark-the-timestamp-without/ba-p/50586&#34;&gt;always stores timestamps converted to UTC, and always displays these timestamps converted to the session-global timezone&lt;/a&gt;.&lt;/p&gt;&#xA;&lt;p&gt;Admittedly, the situation is equally bad with PostgreSQL&amp;rsquo;s &lt;code&gt;TIMESTAMPTZ&lt;/code&gt; type, leading to designs where the actual timezone offset must be stored as a separate timezone offset column.&lt;/p&gt;&#xA;&lt;p&gt;Having a timezone-aware timestamp type that could store the input timezone natively, and which would always display with its full timezone information, would have been much more useful. In our case, we not only need to know the exact timepoint that one of our vision sensors generated a measurement, but we also need to know what the exact &lt;em&gt;local&lt;/em&gt; time was for that specific measurement.&lt;/p&gt;</description>
			</item>
			<item>
				<title>Conservative rendering and liberal parsing of ISO 8601 timestamps in Python</title>
				<link>https://vxlabs.com/2022/08/05/conservative-rendering-and-liberal-parsing-of-iso-8601-timestamps-in-python/</link>
				<pubDate>Fri, 05 Aug 2022 15:28:00 +0200</pubDate>
				<guid>https://vxlabs.com/2022/08/05/conservative-rendering-and-liberal-parsing-of-iso-8601-timestamps-in-python/</guid>
				<description>&lt;p&gt;You&amp;rsquo;ll see in &lt;a href=&#34;https://bugs.python.org/issue37962&#34;&gt;Python bug 37962&lt;/a&gt; that &lt;a href=&#34;https://docs.python.org/3/library/datetime.html#datetime.datetime.isoformat&#34;&gt;&lt;code&gt;datetime.isoformat()&lt;/code&gt;&lt;/a&gt; and&#xA;&lt;a href=&#34;https://docs.python.org/3/library/datetime.html#datetime.datetime.fromisoformat&#34;&gt;&lt;code&gt;datetime.fromisoformat()&lt;/code&gt;&lt;/a&gt; use a restricted subset of the ISO 8601 timestamp&#xA;formatting standards.&lt;/p&gt;&#xA;&lt;p&gt;This is similar to &lt;a href=&#34;https://www.w3.org/TR/NOTE-datetime&#34;&gt;the subset followed by W3C&lt;/a&gt;.&lt;/p&gt;&#xA;&lt;p&gt;Recently, we ran into the specific issue that &lt;code&gt;fromisoformat()&lt;/code&gt; rejects inputs&#xA;where the timezone is specified as &lt;code&gt;+hhmm&lt;/code&gt; instead of &lt;code&gt;+hh:mm&lt;/code&gt;.&lt;/p&gt;&#xA;&lt;p&gt;Both are allowed by ISO 8601, but only the latter is part of the restricted subset.&lt;/p&gt;&#xA;&lt;p&gt;Following &lt;a href=&#34;https://en.wikipedia.org/wiki/Robustness_principle&#34;&gt;the Robustness principle&lt;/a&gt; (also known as Postel&amp;rsquo;s law) in the design&#xA;of our APIs, we would prefer to&lt;/p&gt;</description>
			</item>
			<item>
				<title>Convert dates to different formats in LibreOffice Calc</title>
				<link>https://vxlabs.com/2014/10/06/convert-dates-to-other-formats-in-libreoffice-calc/</link>
				<pubDate>Mon, 06 Oct 2014 12:51:00 +0000</pubDate>
				<guid>https://vxlabs.com/2014/10/06/convert-dates-to-other-formats-in-libreoffice-calc/</guid>
				<description>&lt;p&gt;I’m helping someone process a collection of research data that has been entered by a third party using Excel. We’re using LibreOffice Calc, because research should be reproducible by anyone, not just those in possession of prioprietary software licenses (this also means that we use R, JGR and &lt;a href=&#34;http://www.deducer.org/&#34;&gt;DeduceR&lt;/a&gt; instead of SPSS and Statistica; perhaps more on that later).&lt;/p&gt;&#xA;&lt;p&gt;After having to fix hundreds of badly entered dates with basic functions (we highly recommend that &lt;a href=&#34;http://xkcd.com/1179/&#34;&gt;ISO 8601 format dates&lt;/a&gt;, i.e. YYYY-MM-DD, are used from the very start, instead of ambiguous local formats), we ended up with a stubborn subset of DD-MM-YYYY formatted dates in cells that explicitly had ISO 8601 format configured.&lt;/p&gt;</description>
			</item>
	</channel>
</rss>
