Ticket #139 (closed defect: fixed)

Opened 8 years ago

Last modified 6 years ago

Timestamp wrong

Reported by: yahoo1st@gmail.com Owned by: alamaison
Priority: minor (e.g. uncommon, cosmetic, has workaround) Milestone: 0.9.x Bug sprint
Component: authentication Version: 0.6.0
Keywords: timestamp issue Cc:

Description

Please correct the bug on the timestamp displayed.
Can it auto take the system time of windows.
Anyway, I checked both my server time are consistent.
Swish does a +8.

It's confusing when the correct time on Linux server is different from what we see.
Thank you.

Change History

comment:1 Changed 8 years ago by alamaison

  • Priority changed from major (significantly impairs experience) to minor (e.g. rare, has workaround, consmetic)

comment:2 Changed 8 years ago by alamaison

  • Status changed from new to accepted

comment:3 Changed 8 years ago by alamaison

  • Milestone changed from 0.6.x Bug sprint to 0.7.x Bug sprint

comment:4 Changed 7 years ago by alamaison

  • Status changed from accepted to closed
  • Resolution set to fixed

In [5227bd311291a7846d352938559e27525acb4cdf/swish]:

Display timestamps in the user's local timezone.

Previously the timestamps were left untranslated from UTC. The result of this was that timestamps appeared to be wrong for a user in a non-UTC/GMT timezone even if the server was in the same timezone as the user.

Fixes #121 and #139.

comment:5 Changed 6 years ago by alamaison

In [a17c4b96a36ab4772e1ef0836bf47961a1fc878f/swish]:

Fix display of modified/accessed dates in local time zone.

Partially reverts 5227bd311291a7846d352938559e27525acb4cdf. That commit changed the code to convert the libssh2 UTC times into the local time zone. However, it appears that Explorer expects the OLE DATE (VT_DATE) variant to be in UTC format, so the timezone conversion is happening twice. Explorer's expectation isn't documented anywhere that we could find. The following docs for PropVariantToFileTime? is the closest we could find:  http://goo.gl/Z56FKb.

It's not clear why we thought commit 5227bd3 fixed #121 and #139 or why those bugs occurred at all. Perhaps a problem elsewhere, that has since been fixed, caused those problems and 5227bd3 masked it despite being the wrong fix. Hopefull this change won't reintroduce those bugs.

Relates #121.
Relates #139.
Fixes #231.

Note: See TracTickets for help on using tickets.