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

Inconsistent date formats for timezone #208

Closed
menakas opened this issue Nov 1, 2018 · 2 comments
Closed

Inconsistent date formats for timezone #208

menakas opened this issue Nov 1, 2018 · 2 comments
Labels
priority: high The issue/PR is high priority—it affects lots of customers substantially, but not critically. type: bug The issue is a confirmed bug.
Milestone

Comments

@menakas
Copy link

menakas commented Nov 1, 2018

In the Scheduled Actions page, the Log Date's format contains UTC whereas the Scheduled Date uses +00:00 to specify timezone

As far as I can see, I do not see Scheduled Date displayed in any other time zone. Would it be good to have a consistent format?

@thenbrent
Copy link
Contributor

Would it be good to have a consistent format?

Yes, for sure! :)

@thenbrent thenbrent added type: bug The issue is a confirmed bug. priority: high The issue/PR is high priority—it affects lots of customers substantially, but not critically. and removed question labels Nov 1, 2018
@thenbrent thenbrent added this to the 2.2.0 milestone Jan 14, 2019
@thenbrent
Copy link
Contributor

It looks like both ActionScheduler_ListTable::get_schedule_display_string() and ActionScheduler_ListTable::get_log_entry_html() are already using the same date format timezone character - e - as part of the full date format string 'Y-m-d H:i:s e'.

However, it appears PHP will display different timezone identifier's, presumably depending on the value passed to the DateTimezone object when it is instantiated.

I tested changing the modifier to T, but the behaviour is similar. It will display GMT+0000 for the scheduled date and UTC for the log entries: http://pic.pros.pr/c494a050fdaf

If changing the timezone format character to O, we get consistent results - the difference to Greenwich time (GMT) in hours, i.e. +0000.

This appears to stem from the same issue as #179 - we don't always have a timezone, sometimes we only have an offset, so we can only ever reliably display an offset.

Abbreviations are easier to grok IMO, but as we can't always guarantee we'll have one, we'll need to use offsets.

thenbrent added a commit that referenced this issue Jan 23, 2019
To avoid displaying inconsitent values for the same thing, like UTC
and GMT+0000.

For more background, see #208 (comment)

Fixes #208
thenbrent added a commit that referenced this issue Jan 23, 2019
To avoid displaying inconsitent values for the same thing, like UTC
and GMT+0000.

For more background, see #208 (comment)

Fixes #208
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
priority: high The issue/PR is high priority—it affects lots of customers substantially, but not critically. type: bug The issue is a confirmed bug.
Projects
None yet
Development

No branches or pull requests

2 participants