Opened 19 years ago
Closed 15 years ago
#85 closed defect (fixed)
Slave does not return UTC timestamps
| Reported by: | webkontakt@… | Owned by: | osimons |
|---|---|---|---|
| Priority: | major | Milestone: | 0.6 |
| Component: | Build slave | Version: | 0.5 |
| Keywords: | Cc: | webkontakt@… | |
| Operating System: | Linux |
Description
According to Master Slave Protocol: "The time attribute contains the date and time (in ISO 8601 format) at which the build was started. These timestamps must be UTC, and must not contain a timezone offset."
But it seems that the slave returns local time including time zone offsets (at least mine does, so I have wrong times in the timeline). Perhaps I missed some documentation, but I did not find anything.
Attachments (1)
Change History (7)
comment:1 Changed 19 years ago by anonymous
- Milestone set to 0.5.1
comment:2 Changed 19 years ago by cmlenz
- Milestone changed from 0.5.1 to 0.6
comment:3 Changed 17 years ago by webkontakt@…
Isn't this bug fixed since ages?
comment:4 follow-up: ↓ 5 Changed 17 years ago by thomas_mueller_ffb
a search for "datetime.now" on the current code base (r521) gave 0 hits. The timestamps are transmitted between slave and master as utc.
The only remaining discussion point is the conversion in web-ui.py where datetime.fromtimestamp is used. The utc value is converted to the local time zone of the server. This could cause confusion if the client is in a different timezone.
Proposal: use fromutctimezone or use the timezone from the client (let the css/javascript convert it during rendering???)
comment:5 in reply to: ↑ 4 Changed 15 years ago by osimons
- Owner changed from cmlenz to osimons
Replying to thomas_mueller_ffb:
The only remaining discussion point is the conversion in web-ui.py where datetime.fromtimestamp is used. The utc value is converted to the local time zone of the server. This could cause confusion if the client is in a different timezone.
You mean the code for setting 'duration' value? That is only used to calculate the difference between two timestamps, and for this use of datetime.timedelta the timezone makes no difference at all as long as they use the same base.
Anyway, I made a patch to reuse the time/date handling routines in Trac which just makes this more explicit. Follows shortly. It may be committed, but makes no real difference.
comment:6 Changed 15 years ago by osimons
- Resolution set to fixed
- Status changed from new to closed
In [659] I've cleaned some remaining datetime code that deals with frontend and master-slave communication, but things should work as before as nothing functional is actually changed.
I'm closing this ticket as fixed for 0.6, and have created #423 as a future task for also converting the remaining internals.
Will have to postpone this to get 0.5.1 out.