logtimestamps need to use standard ISO8601 format #2092

Closed
grarpamp opened this Issue Dec 11, 2012 · 4 comments

Comments

Projects
None yet
4 participants
@grarpamp

Timestamps such as '12/11/12' are ambiguous, unsortable, and more.
ISO8601 was introduced and internationally ratified to fix this.
So you want to say (in extended localtime format) '2012-12-12T21:01:02',
or '20121212T210102' in basic format. Refer to pp:4.3.2 on page 19 of the
spec for a quick picture.

There are also places in the code where the data logged contains
and embedded timestamp in the line... that also needs to use ISO8601.

https://en.wikipedia.org/wiki/ISO_8601
http://dotat.at/tmp/ISO_8601-2004_E.pdf

@Diapolo

This comment has been minimized.

Show comment Hide comment
@Diapolo

Diapolo Dec 12, 2012

Your valuable input is most likely not important enough to result in patches too soon. I just want to say, if you are able to code, your best bet is to create a pull-request for such things :). As I said, thanks for the ideas anyway.

Diapolo commented Dec 12, 2012

Your valuable input is most likely not important enough to result in patches too soon. I just want to say, if you are able to code, your best bet is to create a pull-request for such things :). As I said, thanks for the ideas anyway.

@sipa

This comment has been minimized.

Show comment Hide comment
@sipa

sipa Dec 12, 2012

Member

I've wondered myself why it uses that strange US format, but ti seems it just uses strftime's %x, which outputs "The preferred date representation for the current locale without the time.". I've probably set my locale to something US-like. I wouldn't mind changing it to a standard format, though.

Member

sipa commented Dec 12, 2012

I've wondered myself why it uses that strange US format, but ti seems it just uses strftime's %x, which outputs "The preferred date representation for the current locale without the time.". I've probably set my locale to something US-like. I wouldn't mind changing it to a standard format, though.

@grarpamp

This comment has been minimized.

Show comment Hide comment
@grarpamp

grarpamp Dec 12, 2012

The US prefers stupid :( No idea which LC_TIME might do ISO8601, doubt anyone would know to set it, and it wouldn't conform anyways because only part of the string (the %x) is covered by LC_TIME, the rest is hardcoded such that it won't be ISO8601.
This should be most of them...
find -sE . ! -regex '^./.git/.$' -type f | xargs egrep -i 'datetimestrformat|%(y|h|m|x)|gmt|utc'

ISO8601 basic format: %Y%m%dT%H%M%S
Though neither ISO8601 or human, there is one other possible format for use in computing where automated use is expected, the epoch (%s).

The US prefers stupid :( No idea which LC_TIME might do ISO8601, doubt anyone would know to set it, and it wouldn't conform anyways because only part of the string (the %x) is covered by LC_TIME, the rest is hardcoded such that it won't be ISO8601.
This should be most of them...
find -sE . ! -regex '^./.git/.$' -type f | xargs egrep -i 'datetimestrformat|%(y|h|m|x)|gmt|utc'

ISO8601 basic format: %Y%m%dT%H%M%S
Though neither ISO8601 or human, there is one other possible format for use in computing where automated use is expected, the epoch (%s).

@gavinandresen

This comment has been minimized.

Show comment Hide comment
@gavinandresen

gavinandresen Dec 14, 2012

Contributor

Fix merged for 0.8.

Contributor

gavinandresen commented Dec 14, 2012

Fix merged for 0.8.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment