Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ZFS snapshots between midnight and 1 AM are missing a padded zero in the creation propery #10090

Closed
darkpixel opened this issue Mar 1, 2020 · 6 comments
Labels
good first issue Indicates a good issue for first-time contributors Type: Defect Incorrect behavior (e.g. crash, hang)

Comments

@darkpixel
Copy link

darkpixel commented Mar 1, 2020

System information

Distribution Name | Proxmox
Distribution Version |
Linux Kernel | 5.3.10-1-pve
Architecture | x86_64
ZFS Version | 0.8.2-pve2
SPL Version | 0.8.2-pve2

Describe the problem you're observing

The creation property on snapshots is missing the trailing zero when the hour is midnight.

Describe how to reproduce the problem

zfs create tank/users
Between 00:00 and 00:59 hours, do:

zfs snapshot tank/users@mysnapshot
zfs get creation -o value -H tank/users@mysnapshot
Tue Feb 25  0:06 2020

Notice the hours are 0:06
It should be 00:06.

This wreaks havoc on every date parser I can think to use and every format string I can come up with.

This problem may exist elsewhere in date outputs, but I'm currently running into this one.

@gdevenyi
Copy link
Contributor

gdevenyi commented Mar 1, 2020

Oh my why isn't this in ISO format...

@darkpixel
Copy link
Author

Well...there is that...but I'll take whatever reasonable date format I can get. :)

@bghira
Copy link

bghira commented Mar 1, 2020

zfs get -p

@darkpixel
Copy link
Author

I completely missed the -p arg in the docs. Thanks!

Should this be closed since the -p option is available? While the default output format is ugly I'm not entirely sure if it's a bug or not.

@gdevenyi
Copy link
Contributor

gdevenyi commented Mar 3, 2020

I would say both the original question and -p need to be better documented.

I can't tell what format "creation" is supposed to be in (and if its configurable somewhere), and I also can't tell what units it is if -p is specified (although I can guess)

@behlendorf behlendorf added good first issue Indicates a good issue for first-time contributors Type: Defect Incorrect behavior (e.g. crash, hang) labels Mar 3, 2020
@behlendorf
Copy link
Contributor

I'd like to see the missing zero padding added if anyone wants to tackle this. I agree it's jarring to read. And documentation improvements for -p would be welcome.

spaghetti- added a commit to spaghetti-/zfs that referenced this issue Mar 25, 2020
Issue openzfs#10090 reported that snapshots created between midnight and 1 AM
are missing a padded zero in the creation property

This change fixes the bug reported in issue openzfs#10090 where snapshots
created between midnight and 1 AM were missing a padded zero in the
creation timestamp output.

The leading zero was missing because the time format string used `%k`
which formats the hour as a decimal number from 0 to 23 where single
digits are preceded by blanks[0] and is fixed by changing it to `%H`
which formats the hour as 00-23.

The difference in output is as below

```
-Thu Mar 26  0:39 2020
+Thu Mar 26 00:39 2020
```

Signed-off-by: Alex John <alex@stty.io>
tonyhutter pushed a commit to tonyhutter/zfs that referenced this issue Apr 22, 2020
Issue openzfs#10090 reported that snapshots created between midnight and 1 AM
are missing a padded zero in the creation property

This change fixes the bug reported in issue openzfs#10090 where snapshots
created between midnight and 1 AM were missing a padded zero in the
creation timestamp output.

The leading zero was missing because the time format string used `%k`
which formats the hour as a decimal number from 0 to 23 where single
digits are preceded by blanks[0] and is fixed by changing it to `%H`
which formats the hour as 00-23.

The difference in output is as below

```
-Thu Mar 26  0:39 2020
+Thu Mar 26 00:39 2020
```

Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Igor Kozhukhov <igor@dilos.org>
Reviewed-by: George Melikov <mail@gmelikov.ru>
Signed-off-by: Alex John <alex@stty.io>
Closes openzfs#10090 
Closes openzfs#10153
tonyhutter pushed a commit to tonyhutter/zfs that referenced this issue Apr 22, 2020
Issue openzfs#10090 reported that snapshots created between midnight and 1 AM
are missing a padded zero in the creation property

This change fixes the bug reported in issue openzfs#10090 where snapshots
created between midnight and 1 AM were missing a padded zero in the
creation timestamp output.

The leading zero was missing because the time format string used `%k`
which formats the hour as a decimal number from 0 to 23 where single
digits are preceded by blanks[0] and is fixed by changing it to `%H`
which formats the hour as 00-23.

The difference in output is as below

```
-Thu Mar 26  0:39 2020
+Thu Mar 26 00:39 2020
```

Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Igor Kozhukhov <igor@dilos.org>
Reviewed-by: George Melikov <mail@gmelikov.ru>
Signed-off-by: Alex John <alex@stty.io>
Closes openzfs#10090 
Closes openzfs#10153
tonyhutter pushed a commit to tonyhutter/zfs that referenced this issue Apr 28, 2020
Issue openzfs#10090 reported that snapshots created between midnight and 1 AM
are missing a padded zero in the creation property

This change fixes the bug reported in issue openzfs#10090 where snapshots
created between midnight and 1 AM were missing a padded zero in the
creation timestamp output.

The leading zero was missing because the time format string used `%k`
which formats the hour as a decimal number from 0 to 23 where single
digits are preceded by blanks[0] and is fixed by changing it to `%H`
which formats the hour as 00-23.

The difference in output is as below

```
-Thu Mar 26  0:39 2020
+Thu Mar 26 00:39 2020
```

Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Igor Kozhukhov <igor@dilos.org>
Reviewed-by: George Melikov <mail@gmelikov.ru>
Signed-off-by: Alex John <alex@stty.io>
Closes openzfs#10090 
Closes openzfs#10153
tonyhutter pushed a commit that referenced this issue May 12, 2020
Issue #10090 reported that snapshots created between midnight and 1 AM
are missing a padded zero in the creation property

This change fixes the bug reported in issue #10090 where snapshots
created between midnight and 1 AM were missing a padded zero in the
creation timestamp output.

The leading zero was missing because the time format string used `%k`
which formats the hour as a decimal number from 0 to 23 where single
digits are preceded by blanks[0] and is fixed by changing it to `%H`
which formats the hour as 00-23.

The difference in output is as below

```
-Thu Mar 26  0:39 2020
+Thu Mar 26 00:39 2020
```

Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Igor Kozhukhov <igor@dilos.org>
Reviewed-by: George Melikov <mail@gmelikov.ru>
Signed-off-by: Alex John <alex@stty.io>
Closes #10090 
Closes #10153
jsai20 pushed a commit to jsai20/zfs that referenced this issue Mar 30, 2021
Issue openzfs#10090 reported that snapshots created between midnight and 1 AM
are missing a padded zero in the creation property

This change fixes the bug reported in issue openzfs#10090 where snapshots
created between midnight and 1 AM were missing a padded zero in the
creation timestamp output.

The leading zero was missing because the time format string used `%k`
which formats the hour as a decimal number from 0 to 23 where single
digits are preceded by blanks[0] and is fixed by changing it to `%H`
which formats the hour as 00-23.

The difference in output is as below

```
-Thu Mar 26  0:39 2020
+Thu Mar 26 00:39 2020
```

Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Igor Kozhukhov <igor@dilos.org>
Reviewed-by: George Melikov <mail@gmelikov.ru>
Signed-off-by: Alex John <alex@stty.io>
Closes openzfs#10090 
Closes openzfs#10153
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Indicates a good issue for first-time contributors Type: Defect Incorrect behavior (e.g. crash, hang)
Projects
None yet
Development

No branches or pull requests

4 participants