User account request form: Time stamps captured are incorrect

[cci-moc]

User account request form: Time stamps captured are incorrect

[radonm]

Probably wrong timezone.

…

On 23.10.2017 г. 17:48 ч., pns005 wrote: For example: Approved | 23 Oct 2017 21:25:08 |   | 10/23/2017 21:14:54 | ... The 2nd ("Helpdesk notified") and 4th ("Timestamp") columns above should have read something like "17:...". Appears to be 4 hours difference here. I "think" this problem has been there on-off for a while now. It would be good to get this fixed for real. Piyanai — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#96>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABfSV2l85rJzEiS1Sm2nGBmrSUuFJ0RKks5svQm9gaJpZM4QDi2v>.

[greyspectrum]

Both the Google spreadsheet and the helpdesk-vm are set to UTC. This came up as an issue in July, because at that time, the spreadsheet was set to EST and the helpdesk-vm was on UTC. This made it appear as though incoming requests were made four hours in the future, since UTC is four hours ahead of EST.

The "fix" was to switch the spreadsheet to UTC, so that everything is consistent. I'm loathe to switch the helpdesk-vm to EST, because doing that sort of thing creates problems, so the best solution would be to subtract four hours to the time around line 176 of check-approved-requests.py and then switch the spreadsheet back to EST.

That way, the helpdesk-vm stays on UTC, the output in the spreadsheet would be consistent EST, and there would be no daylight-savings-type headaches arising from running a Linux server on non-UTC time.

[jeremyfreudberg]

Was about to comment the same as Austin. We want to always stay on UTC because the occasional switch from EDT to EST and back can be a mess

[radonm]

Why is there an issue then ?

…

On 23.10.2017 г. 19:21 ч., Jeremy Freudberg wrote: Was about to comment the same as Austin. We want to always stay on UTC because the occasional switch from EDT to EST and back can be a mess — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#96 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABfSVxPXVN4mV0ZXzBa4bZir2sKFMeNWks5svR9wgaJpZM4QDi2v>.

[radonm]

And EDT <> EST switch is completely automatic for quite many years....

…

On 23.10.2017 г. 19:21 ч., Jeremy Freudberg wrote: Was about to comment the same as Austin. We want to always stay on UTC because the occasional switch from EDT to EST and back can be a mess — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#96 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABfSVxPXVN4mV0ZXzBa4bZir2sKFMeNWks5svR9wgaJpZM4QDi2v>.

[jeremyfreudberg]

@Radomn in the code we need to keep track of events in UTC. otherwise how do you differentiate Nov 5 2017 at 1:30AM half an hour before the switch and Nov 5 2017 at 1:30 am half an hour after the switch. I guess if you want "human readable" notifications then we can convert the time just for the purposes of displaying in email but it is more of a chore to do that then actually use a negligible amount of brain power to be comfortable with UTC.

[radonm]

I doesn't really matter how you do it as long as it works which is does not at the moment. As far as troubles switching daylight time - total bullshit.

…

On 23.10.2017 г. 21:00 ч., Jeremy Freudberg wrote: @Radomn in the code we need to keep track of events in UTC. otherwise how do you differentiate Nov 5 2017 at 1:30AM half an hour before the switch and Nov 5 2017 at 1:30 am half an hour after the switch. I guess if you want "human readable" notifications then we can convert the time just for the purposes of displaying in email but it is more of a chore to do that then actually use a negligible amount of brain power to be comfortable with UTC. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#96 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABfSV7aAmOW0YGtCh6Iwoq6dl6-kPeoQks5svTbGgaJpZM4QDi2v>.

[radonm]

Port problem should be higher priority. @pns can you approve ports = 3* VMs

[greyspectrum]

The user facing timestamps displayed in the spreadsheet can be converted to EST using pytz, without adjusting the system clock. Running systems on UTC to avoid the kinds of DST problems that Jeremy highlighted is a widely accepted best practice.

[radonm]

Practice that does not work can't be best