I really think you are confusing IP fragmentation with TCP segmentation. Those are two very different things.
Assuming you mean that TCP is given 1800 octets of data from the application, then you will not have any fragmentation at all. TCP will segment the data into two TCP segments that fit into the 1500 octet MTU with no fragmentation. One segment will have 1460 octets of application data (20 octets of TCP header, and 20 octets of IPv4 header, for a total of 1500 octets to meet the MTU), and another segment with 340 octets of application data.
Fragmentation happens when the MTU in the path shrinks and an IP packet is larger than the MTU. In the above scenario, if the MTU on one hop is 1400 octets, then the first IPv4 packet must be fragmented or dropped. The 1500 octet packet will be fragmented into two packets, one of 1396 octets with a payload of 1376 octets (20 octets of TCP header plus 1356 octets of application data), and one of 124 octets with a payload of 104 octets of application data. The other original IP packet fits the new MTU, so it is not fragmented.
When the fragments are received at the destination, the packet fragments are reassembled before IPv4 passes the segment up to TCP, so TCP has no idea that the packet was fragmented. TCP deals with the data segmentation.
IPv6 has eliminated in-path fragmentation because it is resource intensive, and it slows packet delivery. Also, smart businesses will drop IPv4 packet fragments at the firewall to prevent fragmentation attacks. Today, we have PMTUD (Path MTU Discovery) that is used to determine the smallest MTU in the path so that packets can be properly sized to prevent the need for fragmentation in the path.