The Wiert Corner – irregular stream of stuff

Jeroen W. Pluimers on .NET, C#, Delphi, databases, and personal interests

  • My badges

  • Twitter Updates

  • My Flickr Stream

  • Pages

  • All categories

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 2,952 other followers

Archive for the ‘ISO 8601’ Category gets it consistently wrong, Twitter has it right: posting time stamps

Posted by jpluimers on 2022/11/15

UTC and time zones are both hard, especially with respect to scheduling.

The easiest would be to schedule things and store the time zone offsets together with the timestamp, just as ISO 8601 has UTC-relative time zone designators, or alternatively store the region in addition to the timestamp (which can be more user friendly).

When a scheduling system uses local time for schedules, you can expect these will adhere to your local time when the schedule becomes in effect.

So I schedule my posts for 06:00, 12:00 and 18:00 local time during weekdays.

Look what happens:

  1. [] Jeroen Wiert Pluimers on Twitter: “Pro-tip for @wordpressdotcom : fix the scheduler so when you schedule in your local time zone, there is no shift during daylight saving time changes. I schedule all my posts to appear at 06:00 12:00 and 18:00 in my local time. 1/… “
  2. [] Jeroen Wiert Pluimers on Twitter: “That works fine during winter time, which is ~5 out of 12 months, for example 2/… “
  3. [] Jeroen Wiert Pluimers on Twitter: “However 7 out of 12 months, they get posted at 07:00 13:00 and 19:00 local time, for example  3/3… “

Via [] Colin Nederkoorn on Twitter: “Pro tip: Don’t schedule recurring meetings in UTC if you live in a place with daylight savings.… “ (which I do not agree with, see my post UTC and ISO 8601, or GTFO).


Posted in Development, ISO 8601, Power User, Software Development, UTC, Web Development | Leave a Comment »

UTC and ISO 8601, or GTFO

Posted by jpluimers on 2022/11/08

Always schedule your meetings in UTC, and use ISO-8601 date and time notation. Because time zone conversions are hard, especially with so many daylight saving time conventions.

I want not just a “UTC or GTFO” shirt, but a “UTC and ISO-8601, or GTFO” shirt.

It means I do not agree with [] Colin Nederkoorn on Twitter: “Pro tip: Don’t schedule recurring meetings in UTC if you live in a place with daylight savings.… “ with multi-time zone teams: having it in UTC will balance out the DST changes over the teams.

Some more relevant Tweets that triggered me writing this post:

Read the rest of this entry »

Posted in Algorithms, Development, ISO 8601, Power User, Software Development, UTC | Leave a Comment »

Timestamp Generator / Converter –

Posted by jpluimers on 2018/11/16

I wish Google Search would return this when asking for “current time in ISO 8601”: [WayBackTimestamp Generator / Converter –

Type Value
Timestamp 1497872708
Server time 2017-06-19T11:52:55+00:00
ISO 8601 2017-06-19T11:45:08+00:00
RFC 2822 Mon, 19 Jun 2017 11:45:08 +0000
Day of the Week Monday
+1 Hour 1497876308
+1 Day 1497959108
+1 Week 1498477508
+1 Month 1500464708
+1 Year 1529408708


Posted in ISO 8601, LifeHacker, Power User | Leave a Comment »

In C#, given a DateTime object, how do I get a ISO8601 date in string format? – Stack Overflow

Posted by jpluimers on 2014/04/22

The first bulleted link below has been living in my drafts like forever (i.e. somewhere since mid June 2009), so time to write a bit about ISO 8601 and .NET.

First a few links about converting a DateTime into ISO 8601 string format:

Some solutions use the “K” as a time zone specifier. At first, I couldn’t find any documentation for it, not even Google Search for Google Search for “ssK” DateTime ToString returns anything useful.

Later on, I found The “K” Custom Format Specifier in Custom Date and Time Format Strings.

So my preferred solutions for me are these:

  • System.DateTime.Now.ToString("yyyy-MM-ddTHH:mm:ssK");
  • System.DateTime.Now.ToUniversalTime().ToString("yyyy-MM-ddTHH:mm:ssK");

I avoid these:

  • System.DateTime.Now.ToString("o");
    because it gets you too many digits in the second fracion.
  • System.DateTime.Now.ToUniversalTime().ToString("s") + "Z";
    because it is less clear what it does (might be resolved with a comment).



Posted in .NET, .NET 2.0, .NET 3.0, .NET 3.5, .NET 4.0, .NET 4.5, C#, C# 2.0, C# 3.0, C# 4.0, C# 5.0, Development, ISO 8601, Software Development | 1 Comment »

Please write dates and times so that everyone understands them, not just you. xkcd: ISO 8601

Posted by jpluimers on 2013/02/28

ISO 8601 was published on 06 05 88 and most recently amended on 12 01 04

ISO 8601 was published on 06 05 88 and most recently amended on 12 01 04

Boy, am I glad with the xkcd: ISO 8601 post and image on the right.

One reason:

Please write dates and times so that everyone understands them, not just you.

The alt-text of the comic is hilarious (ISO 8601 was published on 06 05 88 and most recently amended on 12 01 04) showing the confusion of using 2 digit years not knowing which field means which (I thin XKCD author Randall Munroe and Mathematics of the ISO calendar got some of the dates, see PDF search dates below).

I found out in the mid 1980s that people I was communicating with internationally (back then the internet was forming and you already had BITNET Relay chat and email) were using different date formats than I did.

Ever since that, I’ve used the YYYY-MM-DD format of writing dates, encouraging others to use as well and as soon as I found out that was a standard, started to evangelize ISO 8601 (there is an ISO 8601 category on my blog), which – at the time of writing this – had had revisions in 1998 (on 1998-06-15), 2000 (on 2000-12-15) and 2004 (on 2004-12-01).

A lot later I found out that back in 1971, this date format was a recommendation, and in 1976 already a standard. Not nearly as old as Esperanto though (:

Speaking about languages:

At the end of last century, after Delphi 5 added year 2000 support (which made the 16-bit Delphi 1 disappear from the box as the effort to prove the product including all libraries was year 2000 proof), Delphi went cross platform.

The Delphi team working on both Kylix 1 and Delphi 6, the also added a DateUtils unit which provides a lot of cuntionality, including support for weak numbers. The first test version always assumed week 1 was the one with januari first in it. As ISO 8601 also indicates how the first week of a year should be determined, a couple of people (Jeroen W. Pluimers, Glenn Crouch, Rune Moberg and  Ray Lischner) provided code that fixed this and a few other things in the unit. We even got mentioned by Cary Jensen!

That code is now also part of the RemObjects ShineOn library. That DateUtils unit is now on GitHub.
A Delphi XE version of the code (and a Delphi 2007 one) are now at NickDemoCode (Thanks Nick Hodges!).

Delphi is not the only environment having ISO 8601 support. XML has, .NET has, etc: it is now wide spread.
So follow your tools, and start using it yourself as well (:

Too bad the ISO 8601 standard text is not available publicly:

I remember the Y2K preparation era where the ISO-8601 standard was freely available at, soon after the Year 2000, the PDF got locked behind a payment engine.
ISO suffers from heavy link rot too, for instance the ISO 3166 country codes used to be at, but are now at What about HTTP 303 or 302 redirect here guys?

Luckily people keep cached copies:

  1. “ISO 8601” “First edition” “1988-06-15” filetype:pdf
  2. “ISO 8601” “Second edition” “2000-12-15” filetype:pdf
  3. “ISO 8601” “Third edition” “2004-12-01” filetype:pdf


via: xkcd: ISO 8601.

Posted in .NET, Delphi, Delphi 2005, Delphi 2006, Delphi 2007, Delphi 2009, Delphi 2010, Delphi 6, Delphi 7, Delphi 8, Delphi x64, Delphi XE, Delphi XE2, Delphi XE3, Development, ISO 8601, Power User, Prism, Software Development | Tagged: , , , , , , , , , , , , , | 10 Comments »

%d bloggers like this: