Repository navigation
Get-Date -UFormat inconsistencies compared to Linux strftime #4750
Description
Activity
- changed the title
[-]Get-Date -UFormat inconsitencies compared to Linux strftime[/-][+]Get-Date -UFormat inconsistencies compared to Linux strftime[/+]on Sep 4, 2017 It seems the formatting can differ between different Linux distributions (I tested on WSL) so I would exclude such points from the Issue.
Please reformat the Issue.
I've checked on Ubuntu 14.04, Ubuntu 16.04 and CentOS 7 machines and the formatting is consistent between them. I don't have a machine with WSL on it handy at the moment to test. Furthermore, the descriptions of the format codes in the strftime man pages do specify format. For instance %k - Get-Date current behaviour is to output with a leading zero, whereas per stfrtime man page:
The hour (24-hour clock) as a decimal number (range 0 to 23); single digits are preceded by a blank.
What formatting changes do you want me to make to the issue?
What formatting changes do you want me to make to the issue?
It is difficult to read the Issue description 😕
Steve Lee (@SteveL-MSFT) Should we fix the formattings? Do PowerShell-Committee conclusion in #4508 cover this?
Is there a RFC or something more canonical than specific distro implementations we can refer to?
Regarding formatting of the issue, I can read each format and the comparison between PowerShell and Linux, so it seems readable enough to me. Ilya (@iSazonov) if you have a suggestion on how to make this more readable, feel free to offer it. It's just long which makes it difficult, but probably better than having multiple separate issues. Per the ietf link, I believe we should be prefixing with zeros so that there's always two digits, but I'm no expert on this topic.
I slightly reformatted.
I agree that we only need the one Issue. Based on #4508 long discussion it seems better to fix each position in a separate PR where discuss, fix and add tests.- addedIssue-BugIssue has been identified as a bug in the productIssue has been identified as a bug in the product
on Sep 5, 2017 Ilya (@iSazonov) agree that it would be better to have separate PRs making it easier to review. Also, are these all things we should change in PowerShell or should they be changes in corefx? Some formats I believe the cmdlet implements, but some come from corefx.
I don't analyze all but it seems most should be fixed in PowerShell repo.
Reacted by Steve LeeOpen #4796 to fix %c.
Open #4805 to fix %j.
The
%uformat specifier should also be included. ISO says Sunday is 7, not 0.%u
The ISO 8601 day of the week 1-7 (M-Su).
en-US
PowerShell
[System.Threading.Thread]::CurrentThread.CurrentCulture = [System.Globalization.CultureInfo]::GetCultureInfo('en-US') get-date -Year 2005 -Month 1 -Day 2 -Hour 1 -Minute 0 -Second 0 -UFormat %u
0Linux
LC_TIME="en_US.UTF-8" date -d 2005-01-02T01:00:00 +%u7
This is important in order to format an accurate ISO8601 week date 📺, using
%G-W%V-%u, which all have to work consistently with each other.%G-W%V-%u
The ISO 8601 week-based date.
en-US
PowerShell
[System.Threading.Thread]::CurrentThread.CurrentCulture = [System.Globalization.CultureInfo]::GetCultureInfo('en-US') get-date -Year 2021 -Month 1 -Day 3 -Hour 1 -Minute 0 -Second 0 -UFormat %G-W%V-%u
2021-W53-0Linux
LC_TIME="en_US.UTF-8" date -d 2021-01-03T01:00:00 +%G-W%V-%u2020-W53-7Reacted by sjoyce28 remaining items
microsoft-github-policy-service commented
on Nov 16, 2023 ContributorMore actionsThis issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.
microsoft-github-policy-service commented
on Nov 16, 2023 ContributorMore actionsThis issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.
- addedResolution-No ActivityIssue has had no activity for 6 months or moreIssue has had no activity for 6 months or more
on Nov 16, 2023 microsoft-github-policy-service commented
on Nov 16, 2023 ContributorMore actionsThis issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.
It looks like there is more work to do, just based on a quick test of the value
2023-11-14T14:13:20-08:format Linux dateGet-Date -UFormat%cTue Nov 14 14:13:20 2023Tue 14 Nov 2023 14:13:20%D11/14/2311-14-23%f000000f%U4645%W4645%x11/14/2311-14-23%Z-08Z%z-0800z%:z-08:00:z%::z-08:00:00::z%:::z-08:::zIt looks like
%ealso fails at times. Here are some examples of the 12 failing format specifiers:Some
Get-Date -UnixTimeSeconds $Epoch -UFormat "%$Format"values
that don't matchdate --date="@$Epoch" "+%$Format"Format Epoch DateTimeOffset Result Actual :::z1193532346 10/27/2007 17:45:46 -07:00 -07:::z:::z1411440574 09/22/2014 19:49:34 -07:00 -07:::z:::z1133655724 12/03/2005 16:22:04 -08:00 -08:::z:::z1063344280 09/11/2003 22:24:40 -07:00 -07:::z:::z959191225 05/24/2000 11:00:25 -07:00 -07:::z:::z1368712450 05/16/2013 06:54:10 -07:00 -07:::z:::z1219137994 08/19/2008 02:26:34 -07:00 -07:::z:::z1675980226 02/09/2023 14:03:46 -08:00 -08:::z:::z1408200835 08/16/2014 07:53:55 -07:00 -07:::z:::z957408718 05/03/2000 19:51:58 -07:00 -07:::z:::z1393628515 02/28/2014 15:01:55 -08:00 -08:::z:::z947689501 01/12/2000 07:05:01 -08:00 -08:::z:::z1219515313 08/23/2008 11:15:13 -07:00 -07:::z:::z1065829381 10/10/2003 16:43:01 -07:00 -07:::z:::z1666846504 10/26/2022 21:55:04 -07:00 -07:::z:::z1396048561 03/28/2014 16:16:01 -07:00 -07:::z:::z1568184091 09/10/2019 23:41:31 -07:00 -07:::z:::z1468025413 07/08/2016 17:50:13 -07:00 -07:::z:::z1624235479 06/20/2021 17:31:19 -07:00 -07:::z:::z1596261829 07/31/2020 23:03:49 -07:00 -07:::z::z1193532346 10/27/2007 17:45:46 -07:00 -07:00:00::z::z1411440574 09/22/2014 19:49:34 -07:00 -07:00:00::z::z1133655724 12/03/2005 16:22:04 -08:00 -08:00:00::z::z1063344280 09/11/2003 22:24:40 -07:00 -07:00:00::z::z959191225 05/24/2000 11:00:25 -07:00 -07:00:00::z::z1368712450 05/16/2013 06:54:10 -07:00 -07:00:00::z::z1219137994 08/19/2008 02:26:34 -07:00 -07:00:00::z::z1675980226 02/09/2023 14:03:46 -08:00 -08:00:00::z::z1408200835 08/16/2014 07:53:55 -07:00 -07:00:00::z::z957408718 05/03/2000 19:51:58 -07:00 -07:00:00::z::z1393628515 02/28/2014 15:01:55 -08:00 -08:00:00::z::z947689501 01/12/2000 07:05:01 -08:00 -08:00:00::z::z1219515313 08/23/2008 11:15:13 -07:00 -07:00:00::z::z1065829381 10/10/2003 16:43:01 -07:00 -07:00:00::z::z1666846504 10/26/2022 21:55:04 -07:00 -07:00:00::z::z1396048561 03/28/2014 16:16:01 -07:00 -07:00:00::z::z1568184091 09/10/2019 23:41:31 -07:00 -07:00:00::z::z1468025413 07/08/2016 17:50:13 -07:00 -07:00:00::z::z1624235479 06/20/2021 17:31:19 -07:00 -07:00:00::z::z1596261829 07/31/2020 23:03:49 -07:00 -07:00:00::z:z1193532346 10/27/2007 17:45:46 -07:00 -07:00:z:z1411440574 09/22/2014 19:49:34 -07:00 -07:00:z:z1133655724 12/03/2005 16:22:04 -08:00 -08:00:z:z1063344280 09/11/2003 22:24:40 -07:00 -07:00:z:z959191225 05/24/2000 11:00:25 -07:00 -07:00:z:z1368712450 05/16/2013 06:54:10 -07:00 -07:00:z:z1219137994 08/19/2008 02:26:34 -07:00 -07:00:z:z1675980226 02/09/2023 14:03:46 -08:00 -08:00:z:z1408200835 08/16/2014 07:53:55 -07:00 -07:00:z:z957408718 05/03/2000 19:51:58 -07:00 -07:00:z:z1393628515 02/28/2014 15:01:55 -08:00 -08:00:z:z947689501 01/12/2000 07:05:01 -08:00 -08:00:z:z1219515313 08/23/2008 11:15:13 -07:00 -07:00:z:z1065829381 10/10/2003 16:43:01 -07:00 -07:00:z:z1666846504 10/26/2022 21:55:04 -07:00 -07:00:z:z1396048561 03/28/2014 16:16:01 -07:00 -07:00:z:z1568184091 09/10/2019 23:41:31 -07:00 -07:00:z:z1468025413 07/08/2016 17:50:13 -07:00 -07:00:z:z1624235479 06/20/2021 17:31:19 -07:00 -07:00:z:z1596261829 07/31/2020 23:03:49 -07:00 -07:00:zc1193532346 10/27/2007 17:45:46 -07:00 Sat Oct 27 17:45:46 2007Sat 27 Oct 2007 17:45:46c1411440574 09/22/2014 19:49:34 -07:00 Mon Sep 22 19:49:34 2014Mon 22 Sep 2014 19:49:34c1133655724 12/03/2005 16:22:04 -08:00 Sat Dec 3 16:22:04 2005Sat 03 Dec 2005 16:22:04c1063344280 09/11/2003 22:24:40 -07:00 Thu Sep 11 22:24:40 2003Thu 11 Sep 2003 22:24:40c959191225 05/24/2000 11:00:25 -07:00 Wed May 24 11:00:25 2000Wed 24 May 2000 11:00:25c1368712450 05/16/2013 06:54:10 -07:00 Thu May 16 06:54:10 2013Thu 16 May 2013 06:54:10c1219137994 08/19/2008 02:26:34 -07:00 Tue Aug 19 02:26:34 2008Tue 19 Aug 2008 02:26:34c1675980226 02/09/2023 14:03:46 -08:00 Thu Feb 9 14:03:46 2023Thu 09 Feb 2023 14:03:46c1408200835 08/16/2014 07:53:55 -07:00 Sat Aug 16 07:53:55 2014Sat 16 Aug 2014 07:53:55c957408718 05/03/2000 19:51:58 -07:00 Wed May 3 19:51:58 2000Wed 03 May 2000 19:51:58c1393628515 02/28/2014 15:01:55 -08:00 Fri Feb 28 15:01:55 2014Fri 28 Feb 2014 15:01:55c947689501 01/12/2000 07:05:01 -08:00 Wed Jan 12 07:05:01 2000Wed 12 Jan 2000 07:05:01c1219515313 08/23/2008 11:15:13 -07:00 Sat Aug 23 11:15:13 2008Sat 23 Aug 2008 11:15:13c1065829381 10/10/2003 16:43:01 -07:00 Fri Oct 10 16:43:01 2003Fri 10 Oct 2003 16:43:01c1666846504 10/26/2022 21:55:04 -07:00 Wed Oct 26 21:55:04 2022Wed 26 Oct 2022 21:55:04c1396048561 03/28/2014 16:16:01 -07:00 Fri Mar 28 16:16:01 2014Fri 28 Mar 2014 16:16:01c1568184091 09/10/2019 23:41:31 -07:00 Tue Sep 10 23:41:31 2019Tue 10 Sep 2019 23:41:31c1468025413 07/08/2016 17:50:13 -07:00 Fri Jul 8 17:50:13 2016Fri 08 Jul 2016 17:50:13c1624235479 06/20/2021 17:31:19 -07:00 Sun Jun 20 17:31:19 2021Sun 20 Jun 2021 17:31:19c1596261829 07/31/2020 23:03:49 -07:00 Fri Jul 31 23:03:49 2020Fri 31 Jul 2020 23:03:49D1193532346 10/27/2007 17:45:46 -07:00 10/27/0710-27-07D1411440574 09/22/2014 19:49:34 -07:00 09/22/1409-22-14D1133655724 12/03/2005 16:22:04 -08:00 12/03/0512-03-05D1063344280 09/11/2003 22:24:40 -07:00 09/11/0309-11-03D959191225 05/24/2000 11:00:25 -07:00 05/24/0005-24-00D1368712450 05/16/2013 06:54:10 -07:00 05/16/1305-16-13D1219137994 08/19/2008 02:26:34 -07:00 08/19/0808-19-08D1675980226 02/09/2023 14:03:46 -08:00 02/09/2302-09-23D1408200835 08/16/2014 07:53:55 -07:00 08/16/1408-16-14D957408718 05/03/2000 19:51:58 -07:00 05/03/0005-03-00D1393628515 02/28/2014 15:01:55 -08:00 02/28/1402-28-14D947689501 01/12/2000 07:05:01 -08:00 01/12/0001-12-00D1219515313 08/23/2008 11:15:13 -07:00 08/23/0808-23-08D1065829381 10/10/2003 16:43:01 -07:00 10/10/0310-10-03D1666846504 10/26/2022 21:55:04 -07:00 10/26/2210-26-22D1396048561 03/28/2014 16:16:01 -07:00 03/28/1403-28-14D1568184091 09/10/2019 23:41:31 -07:00 09/10/1909-10-19D1468025413 07/08/2016 17:50:13 -07:00 07/08/1607-08-16D1624235479 06/20/2021 17:31:19 -07:00 06/20/2106-20-21D1596261829 07/31/2020 23:03:49 -07:00 07/31/2007-31-20e1133655724 12/03/2005 16:22:04 -08:00 33e1675980226 02/09/2023 14:03:46 -08:00 99e957408718 05/03/2000 19:51:58 -07:00 33e1468025413 07/08/2016 17:50:13 -07:00 88e1473346912 09/08/2016 08:01:52 -07:00 88e1281044332 08/05/2010 14:38:52 -07:00 55e1173183142 03/06/2007 04:12:22 -08:00 66e1218188191 08/08/2008 02:36:31 -07:00 88e1194286984 11/05/2007 10:23:04 -08:00 55e1065400018 10/05/2003 17:26:58 -07:00 55e1367554471 05/02/2013 21:14:31 -07:00 22e1625679700 07/07/2021 10:41:40 -07:00 77e1368048889 05/08/2013 14:34:49 -07:00 88e1354608526 12/04/2012 00:08:46 -08:00 44e1285962490 10/01/2010 12:48:10 -07:00 11e1007605156 12/05/2001 18:19:16 -08:00 55e1070435275 12/02/2003 23:07:55 -08:00 22e1507227556 10/05/2017 11:19:16 -07:00 55e1446544252 11/03/2015 01:50:52 -08:00 33e1002140536 10/03/2001 13:22:16 -07:00 33f1193532346 10/27/2007 17:45:46 -07:00 %fff1411440574 09/22/2014 19:49:34 -07:00 %fff1133655724 12/03/2005 16:22:04 -08:00 %fff1063344280 09/11/2003 22:24:40 -07:00 %fff959191225 05/24/2000 11:00:25 -07:00 %fff1368712450 05/16/2013 06:54:10 -07:00 %fff1219137994 08/19/2008 02:26:34 -07:00 %fff1675980226 02/09/2023 14:03:46 -08:00 %fff1408200835 08/16/2014 07:53:55 -07:00 %fff957408718 05/03/2000 19:51:58 -07:00 %fff1393628515 02/28/2014 15:01:55 -08:00 %fff947689501 01/12/2000 07:05:01 -08:00 %fff1219515313 08/23/2008 11:15:13 -07:00 %fff1065829381 10/10/2003 16:43:01 -07:00 %fff1666846504 10/26/2022 21:55:04 -07:00 %fff1396048561 03/28/2014 16:16:01 -07:00 %fff1568184091 09/10/2019 23:41:31 -07:00 %fff1468025413 07/08/2016 17:50:13 -07:00 %fff1624235479 06/20/2021 17:31:19 -07:00 %fff1596261829 07/31/2020 23:03:49 -07:00 %ffU1411440574 09/22/2014 19:49:34 -07:00 3837U959191225 05/24/2000 11:00:25 -07:00 2120U1675980226 02/09/2023 14:03:46 -08:00 065U957408718 05/03/2000 19:51:58 -07:00 1817U1393628515 02/28/2014 15:01:55 -08:00 088U947689501 01/12/2000 07:05:01 -08:00 021U1666846504 10/26/2022 21:55:04 -07:00 4342U1624235479 06/20/2021 17:31:19 -07:00 2524U1105994338 01/17/2005 12:38:58 -08:00 032U1211773768 05/25/2008 20:49:28 -07:00 2120U1442185567 09/13/2015 16:06:07 -07:00 3736U1099228618 10/31/2004 05:16:58 -08:00 4443U1173183142 03/06/2007 04:12:22 -08:00 099U1065400018 10/05/2003 17:26:58 -07:00 4039U1611315556 01/22/2021 03:39:16 -08:00 033U1011222214 01/16/2002 15:03:34 -08:00 022U1014149689 02/19/2002 12:14:49 -08:00 077U1625679700 07/07/2021 10:41:40 -07:00 2726U1677411436 02/26/2023 03:37:16 -08:00 098U1354608526 12/04/2012 00:08:46 -08:00 4948W1193532346 10/27/2007 17:45:46 -07:00 4342W1411440574 09/22/2014 19:49:34 -07:00 3837W959191225 05/24/2000 11:00:25 -07:00 2120W1675980226 02/09/2023 14:03:46 -08:00 065W957408718 05/03/2000 19:51:58 -07:00 1817W1393628515 02/28/2014 15:01:55 -08:00 088W947689501 01/12/2000 07:05:01 -08:00 021W1666846504 10/26/2022 21:55:04 -07:00 4342W1105994338 01/17/2005 12:38:58 -08:00 032W1173183142 03/06/2007 04:12:22 -08:00 109W1530204982 06/28/2018 09:56:22 -07:00 2625W1194286984 11/05/2007 10:23:04 -08:00 4544W1611315556 01/22/2021 03:39:16 -08:00 033W1011222214 01/16/2002 15:03:34 -08:00 022W1014149689 02/19/2002 12:14:49 -08:00 077W1625679700 07/07/2021 10:41:40 -07:00 2726W1187443198 08/18/2007 06:19:58 -07:00 3332W1677411436 02/26/2023 03:37:16 -08:00 088W1354608526 12/04/2012 00:08:46 -08:00 4948W1495101304 05/18/2017 02:55:04 -07:00 2019x1193532346 10/27/2007 17:45:46 -07:00 10/27/0710-27-07x1411440574 09/22/2014 19:49:34 -07:00 09/22/1409-22-14x1133655724 12/03/2005 16:22:04 -08:00 12/03/0512-03-05x1063344280 09/11/2003 22:24:40 -07:00 09/11/0309-11-03x959191225 05/24/2000 11:00:25 -07:00 05/24/0005-24-00x1368712450 05/16/2013 06:54:10 -07:00 05/16/1305-16-13x1219137994 08/19/2008 02:26:34 -07:00 08/19/0808-19-08x1675980226 02/09/2023 14:03:46 -08:00 02/09/2302-09-23x1408200835 08/16/2014 07:53:55 -07:00 08/16/1408-16-14x957408718 05/03/2000 19:51:58 -07:00 05/03/0005-03-00x1393628515 02/28/2014 15:01:55 -08:00 02/28/1402-28-14x947689501 01/12/2000 07:05:01 -08:00 01/12/0001-12-00x1219515313 08/23/2008 11:15:13 -07:00 08/23/0808-23-08x1065829381 10/10/2003 16:43:01 -07:00 10/10/0310-10-03x1666846504 10/26/2022 21:55:04 -07:00 10/26/2210-26-22x1396048561 03/28/2014 16:16:01 -07:00 03/28/1403-28-14x1568184091 09/10/2019 23:41:31 -07:00 09/10/1909-10-19x1468025413 07/08/2016 17:50:13 -07:00 07/08/1607-08-16x1624235479 06/20/2021 17:31:19 -07:00 06/20/2106-20-21x1596261829 07/31/2020 23:03:49 -07:00 07/31/2007-31-20Z1193532346 10/27/2007 17:45:46 -07:00 PDT-07z1193532346 10/27/2007 17:45:46 -07:00 -0700zz1411440574 09/22/2014 19:49:34 -07:00 -0700zZ1411440574 09/22/2014 19:49:34 -07:00 PDT-07Z1133655724 12/03/2005 16:22:04 -08:00 PST-08z1133655724 12/03/2005 16:22:04 -08:00 -0800zZ1063344280 09/11/2003 22:24:40 -07:00 PDT-07z1063344280 09/11/2003 22:24:40 -07:00 -0700zz959191225 05/24/2000 11:00:25 -07:00 -0700zZ959191225 05/24/2000 11:00:25 -07:00 PDT-07z1368712450 05/16/2013 06:54:10 -07:00 -0700zZ1368712450 05/16/2013 06:54:10 -07:00 PDT-07Z1219137994 08/19/2008 02:26:34 -07:00 PDT-07z1219137994 08/19/2008 02:26:34 -07:00 -0700zZ1675980226 02/09/2023 14:03:46 -08:00 PST-08z1675980226 02/09/2023 14:03:46 -08:00 -0800zz1408200835 08/16/2014 07:53:55 -07:00 -0700zZ1408200835 08/16/2014 07:53:55 -07:00 PDT-07z957408718 05/03/2000 19:51:58 -07:00 -0700zZ957408718 05/03/2000 19:51:58 -07:00 PDT-07%cdiffers by the order of the fields; it doesn't match the POSIX format, but since this format is defined as "The preferred date and time representation for the current locale", there may be some flexibility there.%Dand%xdiffer only by the date separator, which could be due to Windows locale settings. The former indicates a specific separator to use, so it should be changed from using the user-preferred separator to the fixed one. Since the latter is defined as "Locale’s appropriate date representation", there may be some flexibility for that one.%elooks fine; the leading space seems to have confused some testing.%fisn't a format character.%Uand%Wweek numbers seem to be off by one for many (all?) dates. These are the only ones providing numerically incorrect data.%Z%z%:z%::z%:::zthe time zone formats all need work, though%Zis "The timezone name or abbreviation", which suggests some flexibility. The rest are unimplemented.
microsoft-github-policy-service commented
on Nov 27, 2023 ContributorMore actionsThis issue has been marked as "No Activity" as there has been no activity for 6 months. It has been closed for housekeeping purposes.
Reacted by Brian Lalonde- added a commit that references this issue
on Dec 24, 2023 - addedWG-Cmdletsgeneral cmdlet issuesgeneral cmdlet issuesand removed
on Jul 17, 2026
With reference to #4264 first reported by chuanjiao10 - on further examination there are a number of UFormats outputs which diverge from the output under Linux. Because the UFormat parameter is supposed to be UNIX format, the output should match that of the date command (i.e. strftime) on Linux.
It's clear that some of the divergences are simple format issues, for instance leading zeros. Others are down to following the ISO 8601 week date specification (https://en.wikipedia.org/wiki/ISO_week_date). And others appear to be differences between locale data on Linux and .Net. In these latter cases it looks like the C locale is followed, which may actually be the best that can be done given the lack of Linux locale data.
%c
en-US
PowerShell
Linux
LC_TIME="en_US.UTF-8" date -d 2005-01-01T01:00:00 +%cC
PowerShell
Linux
LC_TIME="C.UTF-8" date -d 2005-01-01T01:00:00 +%c%g
en-US
PowerShell
Linux
LC_TIME="en_US.UTF-8" date -d 2005-01-01T01:00:00 +%g%G
en-US
PowerShell
Linux
LC_TIME="en_US.UTF-8" date -d 2005-01-01T01:00:00 +%G%j
en-US
PowerShell
Linux
LC_TIME="en_US.UTF-8" date -d 2005-01-01T01:00:00 +%j%k
en-US
PowerShell
Linux
LC_TIME="en_US.UTF-8" date -d 2005-01-01T01:00:00 +%k%l
en-US
PowerShell
Linux
LC_TIME="en_US.UTF-8" date -d 2005-01-01T01:00:00 +%l%s
en-US
PowerShell
Linux
LC_TIME="en_US.UTF-8" date -d 2005-01-01T01:00:00 +%sLinux
LC_TIME="en_US.UTF-8" date -d 2005-01-01T01:00:00.001 +%s%u
en-US
PowerShell
Linux
LC_TIME="en_US.UTF-8" date -d 2005-01-02T01:00:00 +%u%U
en-US
PowerShell
Linux
LC_TIME="en_US.UTF-8" date -d 2005-01-01T01:00:00 +%U%V
en-US
PowerShell
Linux
LC_TIME="en_US.UTF-8" date -d 2005-01-01T01:00:00 +%V%W
en-US
PowerShell
Linux
LC_TIME="en_US.UTF-8" date -d 2005-01-01T01:00:00 +%W%x
en-US
PowerShell
Linux
LC_TIME="en_US.UTF-8" date -d 2005-01-01T01:00:00 +%xC
PowerShell
Linux
LC_TIME="C.UTF-8" date -d 2005-01-01T01:00:00 +%x%X
en-US
PowerShell
Linux
LC_TIME="en_US.UTF-8" date -d 2005-01-01T01:00:00 +%XC
PowerShell
Linux
LC_TIME="C.UTF-8" date -d 2005-01-01T01:00:00 +%X%Z
en-US
PowerShell
Linux
LC_TIME="en_US.UTF-8" date -d 2005-01-01T01:00:00 +%ZI initially, naively, made PR #4508 for #4264 which simply used the GetWeekOfYear method from the Gregorian Calendar. Unfortunately that is too simplistic, and the formula needs to be followed to determine the correct week number. I suggest that PR be closed and new PRs to be created against this tracking issue. My suggestion is that the Pester tests be broken out into a test per UFormat to make this easier (with the failing tests commented until they can be addressed).