-
Notifications
You must be signed in to change notification settings - Fork 190
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
Dealing with timezones? #180
Comments
The tricky part is that there's two timezones at play:
THis is quite hairy but could be done. @barttenbrinke any thoughts? |
I'm definitely in agreement that this should not be a required CLI parameter. Regarding default behavior, it might make more sense to completely ignore the timezone issue completely and simply report what's in the logfile as it does now in the event that no information is provided by the user at runtime. The param would have to take two values logtimeZone and reportTimeZone maybe something of the form: Thanks for opening up this discussion, I know this is likely to be a whole thing. |
How does the S3 timestamp look? Does it have any timezone info? Because the user friendly thing to do would be to 'auto detect' the source timezone (or fallback to UTC if we have no clue) and to output using the local machine's timezone. |
The timestamp in my S3 logs is formatted like this:
|
Regarding the local machine's timezone I think that's a reasonable default provided there's still a command line option override since it's not necessarily true that the majority of a services users live in the same time zone as the log analyzer. |
Does the standard library have enough timezone support to do this? Or would we need to introduce a runtime dependency for this? |
I'd guess you'd want to include a dependency just to avoid having to implement |
I'm using this gem to analyze some S3 logs where the timestamps are UTC. It doesn't look like there is any option available to convert these to a specific timezone before generating the report.
I guess the biggest issue here aside from how gross working with timezones can be is that we need to tell the program what the current timezone in the log is before even thinking about trying to convert it to a different specific one. Bleh.
Any thoughts on how to best address this?
The text was updated successfully, but these errors were encountered: