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

fix: some ui issue #2952

Merged
merged 14 commits into from
Dec 15, 2023
Merged

fix: some ui issue #2952

merged 14 commits into from
Dec 15, 2023

Conversation

devchenyan
Copy link
Collaborator

@devchenyan devchenyan commented Nov 22, 2023

@devchenyan devchenyan marked this pull request as ready for review November 26, 2023 04:02
@devchenyan
Copy link
Collaborator Author

devchenyan commented Dec 5, 2023

/package
Packaging for test is done in 7095467778. @devchenyan

@FrederLu
Copy link
Collaborator

FrederLu commented Dec 7, 2023

/package Packaging for test is done in 7095467778. @devchenyan

image

There is still a time inconsistency problem on Linux.
image

@devchenyan
Copy link
Collaborator Author

devchenyan commented Dec 8, 2023

When the user's device time is non-East 8 time, the display of the release time may not match the one in the details.

So after communicating with @FrederLu , we consider labelling the release time as East 8 time in the release information. cc @Keith-CY

image

@Keith-CY
Copy link
Collaborator

Keith-CY commented Dec 8, 2023

When the user's device time is non-East 8 time, the display of the release time may not match the one in the details.

So after communicating with @FrederLu , we consider labelling the release time as East 8 time in the release information. cc @Keith-CY

image

The datetime set in the release note is UTC+0, so it can be formatted with the timezone

@devchenyan
Copy link
Collaborator Author

When the user's device time is non-East 8 time, the display of the release time may not match the one in the details.
So after communicating with @FrederLu , we consider labelling the release time as East 8 time in the release information. cc @Keith-CY
image

The datetime set in the release note is UTC+0, so it can be formatted with the timezone

The datetime in releaseNotes is formatted with UTC+8 and can't be formatted with the timezone.

image

@Keith-CY
Copy link
Collaborator

Keith-CY commented Dec 9, 2023

When the user's device time is non-East 8 time, the display of the release time may not match the one in the details.
So after communicating with @FrederLu , we consider labelling the release time as East 8 time in the release information. cc @Keith-CY
image

The datetime set in the release note is UTC+0, so it can be formatted with the timezone

The datetime in releaseNotes is formatted with UTC+8 and can't be formatted with the timezone.

image

My bad, I mean the published_at field of https://api.github.com/repos/nervosnetwork/neuron/releases/tags/v0.111.0 can be formatted with UTC+0, and it's expected to be the same date in the release note.

The date in the release note is updated manually and prone to be wrong, e.g. the release date was updated with an incorrect time but not found in code review(https://github.com/nervosnetwork/neuron/pull/2973/files), but published_at is set by program and more reliable.

@devchenyan
Copy link
Collaborator Author

When the user's device time is non-East 8 time, the display of the release time may not match the one in the details.
So after communicating with @FrederLu , we consider labelling the release time as East 8 time in the release information. cc @Keith-CY
image

The datetime set in the release note is UTC+0, so it can be formatted with the timezone

The datetime in releaseNotes is formatted with UTC+8 and can't be formatted with the timezone.
image

My bad, I mean the published_at field of https://api.github.com/repos/nervosnetwork/neuron/releases/tags/v0.111.0 can be formatted with UTC+0, and it's expected to be the same date in the release note.

The date in the release note is updated manually and prone to be wrong, e.g. the release date was updated with an incorrect time but not found in code review(https://github.com/nervosnetwork/neuron/pull/2973/files), but published_at is set by program and more reliable.

To avoid misunderstanding, we can mark the release time as East 8 district time .eg: 0.112.0 (2023-12-07 UTC+8)

image

@Keith-CY
Copy link
Collaborator

When the user's device time is non-East 8 time, the display of the release time may not match the one in the details.
So after communicating with @FrederLu , we consider labelling the release time as East 8 time in the release information. cc @Keith-CY
image

The datetime set in the release note is UTC+0, so it can be formatted with the timezone

The datetime in releaseNotes is formatted with UTC+8 and can't be formatted with the timezone.
image

My bad, I mean the published_at field of api.github.com/repos/nervosnetwork/neuron/releases/tags/v0.111.0 can be formatted with UTC+0, and it's expected to be the same date in the release note.
The date in the release note is updated manually and prone to be wrong, e.g. the release date was updated with an incorrect time but not found in code review(#2973 (files)), but published_at is set by program and more reliable.

To avoid misunderstanding, we can mark the release time as East 8 district time .eg: 0.112.0 (2023-12-07 UTC+8)

image

Indeed, I will append the timezone in following release notes

@devchenyan
Copy link
Collaborator Author

devchenyan commented Dec 14, 2023

/package
Packaging for test is done in 7203849589. @devchenyan

@devchenyan devchenyan added this pull request to the merge queue Dec 15, 2023
Merged via the queue into develop with commit c2ab3ac Dec 15, 2023
@devchenyan devchenyan deleted the fix-UI-issues branch December 15, 2023 13:50
yanguoyu pushed a commit to yanguoyu/neuron that referenced this pull request Mar 14, 2024
* fix: some ui issue

* fix: some ui issue

* feat: validateCapacity

* fix: syncIcon

* fix: comments

* fix: releaseDate

* fix: Issue on UI withdrawing from NervosDao

* fix: releaseDate

* fix

---------

Co-authored-by: Chen Yu <[email protected]>
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

Successfully merging this pull request may close these issues.

4 participants