### Author:  [@ishantt](https://discuss.elastic.co/u/ishantt)
#### Post date: [September 19, 2015, 6:29pm UTC](https://discuss.elastic.co/t/logstash-bug-with-timestamp/29641/1 "2015-09-19T18:29:31Z")
I need to report back to Logstash community about a bug that i found.
As you can see below, the @timestamp field is populated with date and timestamp in the UTC where as first\_switched and last\_switched are in local time zone (This netflow is generated and in the US Eastern timezone). You will notice that there is a 4 hour difference. 18:39 vs. 14:39.
All the date fields are expected to follow the ISO 8601, which should always be represented in UTC.
"@timestamp": "2015-09-18T18:39:32.000Z",
"netflow": {
"version": 5,
"flow\_seq\_num": 527624356,
"last\_switched": "2015-09-18T14:39:16.000Z",
"first\_switched": "2015-09-18T14:39:16.000Z",
"in\_bytes": 54400,
"in\_pkts": 1600,
"input\_snmp": 3,
"output\_snmp": 1,
"ipv4\_src\_addr": "192.168.19.74",
"ipv4\_dst\_addr": "224.0.0.251",
"protocol": 17,
"src\_tos": 0,
"l4\_src\_port": 5353,
"l4\_dst\_port": 5353,
"ipv4\_next\_hop": "0.0.0.0",
"dst\_mask": 0,
"src\_mask": 0,
"tcp\_flags": 0,
"flow\_records": 3,
"engine\_type": 0,
"dst\_as": 0,
"engine\_id": 0,
"sampling\_algorithm": 0,
"sampling\_interval": 0,
"src\_as": 0
},
---
### Author:  [@magnusbaeck](https://discuss.elastic.co/u/magnusbaeck)
#### Post date: [September 19, 2015, 8:22pm UTC](https://discuss.elastic.co/t/logstash-bug-with-timestamp/29641/2 "2015-09-19T20:22:33Z")
Are you using the netflow codec? As I read its code (at the bottom), Logstash doesn't attempt any kind of timezone adjustments. It assumes all timestamps arrive as UTC over the wire and emits UTC accordingly. I'd make sure that what Logstash gets actually is UTC and not local time.
> All the date fields are expected to follow the ISO 8601, which should always be represented in UTC.
No, ISO8601 doesn't have to be UTC.
>
---
### Author:  [@ishantt](https://discuss.elastic.co/u/ishantt)
#### Post date: [September 20, 2015, 1:46pm UTC](https://discuss.elastic.co/t/logstash-bug-with-timestamp/29641/3 "2015-09-20T13:46:15Z")
what should I do then with this issue? can you help me fix this and make logstash read the time stamp as EDT not UTC?
---
### Author:  [@Joe\_Lawson](https://discuss.elastic.co/u/Joe_Lawson)
#### Post date: [September 20, 2015, 1:52pm UTC](https://discuss.elastic.co/t/logstash-bug-with-timestamp/29641/4 "2015-09-20T13:52:32Z")
Make sure all your systems are using UTC.
---
### Author:  [@magnusbaeck](https://discuss.elastic.co/u/magnusbaeck)
#### Post date: [September 20, 2015, 2:09pm UTC](https://discuss.elastic.co/t/logstash-bug-with-timestamp/29641/5 "2015-09-20T14:09:43Z")
> what should I do then with this issue? can you help me fix this and make logstash read the time stamp as EDT not UTC?
Before going into solution mode we need to have all facts. I'd use Wireshark or similar to capture some of the netflow traffic and inspect what's actually being sent over the wire. If the netflow data indeed uses EDT I'd try to reconfigure whatever device is emitting the data so that it's compliant with the specification. Failing that, I'd see what can be done on the Logstash side. You should be able to use a date filter.
---
### Author:  [@ishantt](https://discuss.elastic.co/u/ishantt)
#### Post date: [September 20, 2015, 5:37pm UTC](https://discuss.elastic.co/t/logstash-bug-with-timestamp/29641/6 "2015-09-20T17:37:36Z")
Hello Magnus,
Thanks for your prompt response.
Yes, we are using the netflow codec and we checked the data on the wire using wireshark to ensure that the timestamps and other fields are correct..
As you will notice in the following packet structure, there are 2 fields in the Flow Header of the netflow and there 2 others in each data record.
We have confirmed that unix\_secs are in the UTC (time epoch), the sys\_uptime value is correct and the last\_switched and first\_switched fields are correct relative to sys\_uptime field.
Another question, we are wondering if @timestamp value is derived from the unix\_secs in the header or from somewhere?
Export packet
Packet Header
Template FlowSet
Data FlowSet
Data FlowSet
...
Template FlowSet
Data FlowSet
...
Flow header format
Bytes Contents Description
0-1 version NetFlow export format version number
2-3 count Number of flow sets exported in this packet, both template and data (1-30).
4-7 sys\_uptime Current time in milliseconds since the export device booted.
8-11 unix\_secs Current count of seconds since 0000 UTC 1970.
12-15 package\_sequence Sequence counter of all export packets sent by the export device. Note: This is a change from the Version 5 and Version 8 headers, where this number represented “total flows.”
16-19 source\_id A 32-bit value that is used to guarantee uniqueness for all flows exported from a particular device. (The Source ID field is the equivalent of the engine type and engine ID fields found in the NetFlow Version 5 and Version 8 headers). The format of this field is vendor specific. In Cisco's implementation, the first two bytes are reserved for future expansion, and will always be zero. Byte 3 provides uniqueness with respect to the routing engine on the exporting device. Byte 4 provides uniqueness with respect to the particular line card or Versatile Interface Processor on the exporting device. Collector devices should use the combination of the source IP address plus the Source ID field to associate an incoming NetFlow export packet with a unique instance of NetFlow on a particular device.
Template FlowSet Format
LAST\_SWITCHED 21 4 System uptime at which the last packet of this flow was switched
FIRST\_SWITCHED 22 4 System uptime at which the first packet of this flow was switched
---
### Author:  [@ishantt](https://discuss.elastic.co/u/ishantt)
#### Post date: [September 20, 2015, 5:41pm UTC](https://discuss.elastic.co/t/logstash-bug-with-timestamp/29641/7 "2015-09-20T17:41:23Z")
Hello Magnus,
Thanks for your prompt response.
Yes, we are using the netflow codec and we checked the data on the wire using wireshark to ensure that the timestamps and other fields are correct..
As you will notice in the following packet structure, there are 2 fields in the Flow Header of the netflow and there 2 others in each data record.
We have confirmed that unix\_secs are in the UTC (time epoch), the sys\_uptime value is correct and the last\_switched and first\_switched fields are correct relative to sys\_uptime field.
Another question, we are wondering if @timestamp value is derived from the unix\_secs in the header or from somewhere?
Export packet
Packet Header
Template FlowSet
Data FlowSet
Data FlowSet
...
Template FlowSet
Data FlowSet
...
Flow header format
Bytes
Contents
Description
0-1
version
NetFlow export format version number
2-3
count
Number of flow sets exported in this packet, both template and data (1-30).
4-7
sys\_uptime
Current time in milliseconds since the export device booted.
8-11
unix\_secs
Current count of seconds since 0000 UTC 1970.
12-15
package\_sequence
Sequence counter of all export packets sent by the export device. Note: This is a change from the Version 5 and Version 8 headers, where this number represented “total flows.”
16-19
source\_id
A 32-bit value that is used to guarantee uniqueness for all flows exported from a particular device. (The Source ID field is the equivalent of the engine type and engine ID fields found in the NetFlow Version 5 and Version 8 headers). The format of this field is vendor specific. In Cisco's implementation, the first two bytes are reserved for future expansion, and will always be zero. Byte 3 provides uniqueness with respect to the routing engine on the exporting device. Byte 4 provides uniqueness with respect to the particular line card or Versatile Interface Processor on the exporting device. Collector devices should use the combination of the source IP address plus the Source ID field to associate an incoming NetFlow export packet with a unique instance of NetFlow on a particular device.
Template FlowSet Format
LAST\_SWITCHED
21
4
System uptime at which the last packet of this flow was switched
FIRST\_SWITCHED
22
4
System uptime at which the first packet of this flow was switched
---
### Author:  [@magnusbaeck](https://discuss.elastic.co/u/magnusbaeck)
#### Post date: [September 20, 2015, 6:05pm UTC](https://discuss.elastic.co/t/logstash-bug-with-timestamp/29641/8 "2015-09-20T18:05:24Z")
> We have confirmed that unix\_secs are in the UTC (time epoch), the sys\_uptime value is correct and the last\_switched and first\_switched fields are correct relative to sys\_uptime field.
Well, then I'm out of ideas. AFAICT Logstash assumes UTC and does not make any timezone adjustments.
> Another question, we are wondering if @timestamp value is derived from the unix\_secs in the header or from somewhere?
The netflow codec itself doesn't touch the `@timestamp` field so unless you use the date filter or by other means manipulate that field it'll contain the time when Logstash first saw the event.
---
### Author:  [@abhisheyke](https://discuss.elastic.co/u/abhisheyke)
#### Post date: [December 14, 2015, 4:55pm UTC](https://discuss.elastic.co/t/logstash-bug-with-timestamp/29641/9 "2015-12-14T16:55:21Z")
It looks like calculation of first\_switched and last\_switched is not correct.
I am not seeing if overflow of sysup time , first and last is taken care.
It is not always true that sysup\_time in header will greater than first and last filed in netflow record.
That is a bug in netflow codec.
---
### Author:  [@system](https://discuss.elastic.co/u/system)
#### Post date: [July 6, 2017, 5:18am UTC](https://discuss.elastic.co/t/logstash-bug-with-timestamp/29641/10 "2017-07-06T05:18:32Z")