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

Timestamps incorrectly stored in local time zone #2718

Open
pki-bot opened this issue Oct 3, 2020 · 3 comments
Open

Timestamps incorrectly stored in local time zone #2718

pki-bot opened this issue Oct 3, 2020 · 3 comments
Milestone

Comments

@pki-bot
Copy link

pki-bot commented Oct 3, 2020

This issue was migrated from Pagure Issue #2598. Originally filed by edewata (@edewata) on 2017-02-17 20:50:53:


In some places the code is encoding timestamps as follows:

SimpleDateFormat formatter = new SimpleDateFormat("yyyyMMddHHmmss'Z'");
String string = formatter.format(timestamp);

However, it does not set the UTC time zone as follows:

formatter.setTimeZone(TimeZone.getTimeZone("UTC"));

So the resulting string is actually still in local time zone instead of UTC as implied by the 'Z' suffix, which could be misleading. Quoted text is not interpreted by the formatter. See http://docs.oracle.com/javase/7/docs/api/java/text/SimpleDateFormat.html.

In DateMapper the problem may affect timestamps stored in the following fields in the database:

  • Certificate record:
    • dateOfCreate
    • dateOfModify
    • revokedOn
    • notAfter
    • notBefore
  • CRL record:
    • thisUpdate
    • nextUpdate
  • Key record:
    • dateOfCreate
    • dateOfModify
    • dateOfRecovery
  • Request record:
    • dateOfCreate
    • dateOfModify

In KRATool it may affect the timestamps stored in the LDIF files generated by this tool.

If everything that needs to use these timestamps (including PKI server) are always in the same time zone, this may not be a problem since encoding and decoding is done consistently using the same formatter. However, if PKI server is cloned/migrated into a different time zone the dates could be incorrectly decoded into the new time zone, possibly causing other issues.

One solution is to fix the timestamps manually in the database/LDIF files whenever the PKI server is cloned/migrated into a different time zone.

Another solution is to create a database upgrade script that will automatically converts the local timestamps into UTC timestamps into new fields and also modify the code to use the new fields and fix the timestamp formatter. This will allow changing time zones without changing the database, also allow clones to run in different time zones.

@pki-bot pki-bot added this to the FUTURE milestone Oct 3, 2020
@pki-bot
Copy link
Author

pki-bot commented Oct 3, 2020

Comment from mharmsen (@mharmsen) at 2017-02-21 22:00:39

Linked to Bugzilla bug: https://bugzilla.redhat.com/show_bug.cgi?id=1424624 (Red Hat Enterprise Linux 7)

@pki-bot
Copy link
Author

pki-bot commented Oct 3, 2020

Comment from edewata (@edewata) at 2017-02-27 14:05:49

Metadata Update from @edewata:

  • Issue set to the milestone: 0.0 NEEDS_TRIAGE

@pki-bot
Copy link
Author

pki-bot commented Oct 3, 2020

Comment from mharmsen (@mharmsen) at 2017-03-03 15:11:37

Metadata Update from @mharmsen:

  • Custom field feature adjusted to ''
  • Custom field proposedmilestone adjusted to '' (was: FUTURE)
  • Custom field proposedpriority adjusted to '' (was: major)
  • Custom field reviewer adjusted to ''
  • Custom field version adjusted to ''
  • Issue close_status updated to: None
  • Issue priority set to: 3
  • Issue set to the milestone: FUTURE (was: 0.0 NEEDS_TRIAGE)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant