Do not use 'created' for time anymore in Start_log_event, it's the same

as the already-stored timestamp. Now 'created' is used only to know if
this is a first binlog or not. And we may re-use the superfluous bytes
in 5.0 when we need room.

sql/log_event.cc

@@ -302,13 +302,11 @@ void Start_log_event::print(FILE* file, bool short_form, char* last_db)
     return;
 
   print_header(file);
-  fprintf(file, "\tStart: binlog v %d, server v %s", binlog_version,
+  fprintf(file, "\tStart: binlog v %d, server v %s created ", binlog_version,
 	  server_version);
+  print_timestamp(file);
   if (created)
-  {
-    fprintf(file, " created ");
-    print_timestamp(file, &created);
-  }
+    fprintf(file," at startup");
   fputc('\n', file);
   fflush(file);
 }

sql/log_event.h

@@ -335,6 +335,17 @@ class Start_log_event: public Log_event
      by FLUSH LOGS or automatic rotation), 'created' should be 0.
      This "trick" is used by MySQL >=4.0.14 slaves to know if they must drop the
      stale temporary tables or not.
+     Note that when 'created'!=0, it is always equal to the event's timestamp;
+     indeed Start_log_event is written only in log.cc where the first
+     constructor below is called, in which 'created' is set to 'when'. 
+     So in fact 'created' is a useless variable. When it is 0
+     we can read the actual value from timestamp ('when') and when it is
+     non-zero we can read the same value from timestamp ('when'). Conclusion:
+     - we use timestamp to print when the binlog was created.
+     - we use 'created' only to know if this is a first binlog or not.
+     In 3.23.57 we did not pay attention to this identity, so mysqlbinlog in
+     3.23.57 does not print 'created the_date' if created was zero. This is now
+     fixed.
   */
   time_t created;
   uint16 binlog_version;