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

displayed date/times are incorrect #117

Closed
Daryes opened this Issue Aug 19, 2017 · 7 comments

Comments

Projects
None yet
2 participants
@Daryes

Daryes commented Aug 19, 2017

Hello,
I would like to have the iso-8601 date format with the complete time zone designation, supported by rundeck, either through a setting or an additional parameter on the command line.

Currently, rundeck-cli return the date in this format : 2017-05-2511:21:00+0200

Using the exact same date and time, iso-8601 date format is very close : 2017-05-25T13:21:00+0200
With a subtle difference : the time is in the local time, when rundeck-cli return the UTC time

Most utilities and languages, starting with the "date" command can immediately understand the iso-8601 date without error, but aren't able to do so with the rundeck-cli default format

@gschueler

This comment has been minimized.

Show comment
Hide comment
@gschueler

gschueler Aug 21, 2017

Member

You can set RD_DATE_FORMAT, although I see it is not documented. It uses the Java SimpleDateFormat syntax.

The default is yyyy-MM-ddHH:mm:ssZ but seems like that is not exactly iso-8601

Member

gschueler commented Aug 21, 2017

You can set RD_DATE_FORMAT, although I see it is not documented. It uses the Java SimpleDateFormat syntax.

The default is yyyy-MM-ddHH:mm:ssZ but seems like that is not exactly iso-8601

@Daryes

This comment has been minimized.

Show comment
Hide comment
@Daryes

Daryes Aug 23, 2017

Useful option. I played with it for a while, and got the wanted format, but it seems there's still a problem, caused by the date package itself : the time is always returned relative to the UTC timezone.

I've search about it, and multiple time it's suggested to not use the default date package, but instead use either the new java.time package in java 8 or Joda-Time.

I've already built a function to deal with this behavior, so no hurry about it, but this switch might be worth considering

Daryes commented Aug 23, 2017

Useful option. I played with it for a while, and got the wanted format, but it seems there's still a problem, caused by the date package itself : the time is always returned relative to the UTC timezone.

I've search about it, and multiple time it's suggested to not use the default date package, but instead use either the new java.time package in java 8 or Joda-Time.

I've already built a function to deal with this behavior, so no hurry about it, but this switch might be worth considering

@gschueler

This comment has been minimized.

Show comment
Hide comment
@gschueler

gschueler Aug 23, 2017

Member

when you say "relative to the UTC timezone" what do you mean? do you have some examples? are you expecting it relative to local system timezone?

also, try using RD_DEBUG=3 to see the API response data. I believe the data is sent in UTC timezone, perhaps we just need a way to convert to another timezone

Member

gschueler commented Aug 23, 2017

when you say "relative to the UTC timezone" what do you mean? do you have some examples? are you expecting it relative to local system timezone?

also, try using RD_DEBUG=3 to see the API response data. I believe the data is sent in UTC timezone, perhaps we just need a way to convert to another timezone

@Daryes

This comment has been minimized.

Show comment
Hide comment
@Daryes

Daryes Aug 24, 2017

Meaning this : local time is 22h10, GMT+1 (with daylight saving time)
Aside the format using UTC as reference, others formats should return either 22:10+0200 or something similar, but using the local time.
Currently, rd-cli return 20:10+0200. I tried with different formats, and the time is always set to the UTC tz, and not relative to the current tz (i.e. : should be 22:.10... ).

btw, I forgot to link a reference : https://stackoverflow.com/a/21940449
But everything I found says the same.

This aside, I ran the test, and the data sent from rundeck to rd-cli is indeed in UTC tz (the following job is scheduled at 06:15 am) :

"executions": [
        {
            "argstring": "-HISTORY_KEEP 5 -HISTORY_STATE succeeded",
            "date-ended": {
                "date": "2017-08-24T04:15:35Z",
                "unixtime": 1503548135537
            },
            "date-started": {
                "date": "2017-08-24T04:15:00Z",
                "unixtime": 1503548100348
            },
            "description": "/server/rundeck/tools/rundeck_history_clear.sh -clear jobs -state ${option.HISTORY_STATE} -keep_count ${option.HISTORY_KEEP} ('nettoyage')",
            "executionType": "scheduled",
            "href": "http://hephaistos.reseau.local:4440/api/20/execution/186",
            "id": 186,
            "job": {
(...)
        },

Casting the date with a forced TZ might correct this, but not sure there wont be a side effect with other TZ

Daryes commented Aug 24, 2017

Meaning this : local time is 22h10, GMT+1 (with daylight saving time)
Aside the format using UTC as reference, others formats should return either 22:10+0200 or something similar, but using the local time.
Currently, rd-cli return 20:10+0200. I tried with different formats, and the time is always set to the UTC tz, and not relative to the current tz (i.e. : should be 22:.10... ).

btw, I forgot to link a reference : https://stackoverflow.com/a/21940449
But everything I found says the same.

This aside, I ran the test, and the data sent from rundeck to rd-cli is indeed in UTC tz (the following job is scheduled at 06:15 am) :

"executions": [
        {
            "argstring": "-HISTORY_KEEP 5 -HISTORY_STATE succeeded",
            "date-ended": {
                "date": "2017-08-24T04:15:35Z",
                "unixtime": 1503548135537
            },
            "date-started": {
                "date": "2017-08-24T04:15:00Z",
                "unixtime": 1503548100348
            },
            "description": "/server/rundeck/tools/rundeck_history_clear.sh -clear jobs -state ${option.HISTORY_STATE} -keep_count ${option.HISTORY_KEEP} ('nettoyage')",
            "executionType": "scheduled",
            "href": "http://hephaistos.reseau.local:4440/api/20/execution/186",
            "id": 186,
            "job": {
(...)
        },

Casting the date with a forced TZ might correct this, but not sure there wont be a side effect with other TZ

@gschueler gschueler added the bug label Aug 24, 2017

@gschueler

This comment has been minimized.

Show comment
Hide comment
@gschueler

gschueler Aug 24, 2017

Member

i think there is a bug converting the date string (in UTC) into the correct date before rd displays it. that is also a separate issue from correctly rendering the parsed date into local time zone

Member

gschueler commented Aug 24, 2017

i think there is a bug converting the date string (in UTC) into the correct date before rd displays it. that is also a separate issue from correctly rendering the parsed date into local time zone

@gschueler gschueler changed the title from Add iso-8601 date format support to displayed date/times are incorrect Aug 24, 2017

gschueler added a commit that referenced this issue Aug 24, 2017

@gschueler gschueler closed this in 2e033e5 Aug 24, 2017

@gschueler

This comment has been minimized.

Show comment
Hide comment
@gschueler

gschueler Aug 25, 2017

Member

try the newest release

Member

gschueler commented Aug 25, 2017

try the newest release

@Daryes

This comment has been minimized.

Show comment
Hide comment
@Daryes

Daryes Aug 30, 2017

Sorry, missed the comment as I didn't check back the issue : though it was closed, and usually, furthers comments are ignored ... most of the time.

When I saw the new version between your 2 posts, I updated rd-cli.
I had to remove all custom date manipulation, because as it's the good news, the new version works as expected. No issue with it, the dependency script I've made could process immediately the date as is.
Thank you.

Daryes commented Aug 30, 2017

Sorry, missed the comment as I didn't check back the issue : though it was closed, and usually, furthers comments are ignored ... most of the time.

When I saw the new version between your 2 posts, I updated rd-cli.
I had to remove all custom date manipulation, because as it's the good news, the new version works as expected. No issue with it, the dependency script I've made could process immediately the date as is.
Thank you.

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