Bug: match endpoint not reporting start_time

Hi,

At least for three matches in registered state I am not getting any value for start time.

In one match, there is no set start time:

https://www.chess.com/club/matches/black-stone/845130

https://api.chess.com/pub/match/845130

Two others have start times according to the website, but they still do not appear at the endpoint:

https://www.chess.com/club/matches/black-stone/865180

https://api.chess.com/pub/match/865180

https://www.chess.com/club/matches/black-stone/865924

https://api.chess.com/pub/match/865924

An in-progress match does deliver start_time:

https://www.chess.com/club/matches/black-stone/724846

https://api.chess.com/pub/match/724846

I'm calling this a bug as it doesn't match the documentation and there seems no reason not to provide it (empty perhaps if "Ask admin"  is what the website displays). It's not high priority however providing all in-progress and finished matches do have their start_time filled in correctly.

(Use case: I am writing an activity report. What was the last match a member played in, or is registered for?)

"start_time":1477843022
                   Are these seconds?

Seconds since the Unix epoch: January 1st 1970 00:00.

Almost certainly POSIX (an industry standard) and thus ignorant of leap seconds, but I think that's a nitpick.

If you have a system with perl installed:

$ perl -e 'print scalar(gmtime(1477843022)), "\n"'

Sun Oct 30 15:57:02 2016

$ perl -e 'print scalar(localtime(1477843022)), "\n"'

Mon Oct 31 02:57:02 2016

In October my local time would be UTC+11, and almost 4pm to almost 3am the following day is 11 hours. Works.

LOL!
I wasn't registed at chess.com back then, must have been craaaazy.

So maybe it's hexadecimal?     ↨wä0"
Hmm maybe not.

Idk how to interpret this number.

It is a pure count of seconds since the start of January 1st 1970. Unix was being developed at Bell Labs in the early 1970s so it was a convenient starting point.

In a non-leap year there are 365 days, so 365 * 24 hours * 60 minutes * 60 seconds = 

31536000s per year. Add one more day's worth for leap years, so they have 

31622400s.

After that it's just "simple" arithmetic to work out what day of what month a timestamp refers to. I say "simple" because calendar arithmetic never is as simple as it appears to be, but by having a monotonically increasing number of seconds in UTC it means for computers time always goes forward and only local representations with time zones and daylight saving time jump about.

Times before 1970 (negative numbers) get a bit trickier, what with the conversion from the Julian to Gregorian calendars which was done at different times (apologies for the pun) in different countries.

  September 1752
Su Mo Tu We Th Fr Sa
       1  2 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30

 P.S. If anyone knows the magic for producing fixed-with text like the above, please share? That was cut, paste, edit, cut other stuff, past, edit ... there must be an easy way!

Tools always. Never by hand. My perl incantation is what I use, but it demonstrates a couple of the reasons perl is not always simple to understand. 

This is easier to use:

https://www.epochconverter.com/