Unix time oddity, or something else?

Question

I'm writing an app in C# that calls methods on a 3rd party web service (but this question is language independent). One of the methods I have to call sets a "start time." The method expects the date and time to be passed as a long, in Unix time format (seconds since midnight on 1/1/70).

The code examples I received from their dev team use the Java getTime() function, which as far as I can tell does indeed return a long representing the Unix time. So for example if I want to set the start time to 2/28/11 at 5pm I would pass it 1298912400. However this doesn't work. Their service doesn't return an error, but if I go look at the web gui to confirm, the start time is blank.

Now, if I use their web gui to manually set the start time to 2/28/11 at 5pm their log shows it as 1298930400000. First, this number is 3 digits too long and second, even if I remove the extra zeros the number equates to 2/28/11 but at 11pm.

So my question is, are they doing something internally that I don't know about, or am I missing something that someone here can point out to me?

Updated to add code:

TimeSpan ts = (new DateTime(2011, 2, 28, 17, 0, 0, DateTimeKind.Utc) - new DateTime(1970, 1, 1, 0, 0, 0, DateTimeKind.Utc));
long goodtime = (long)ts.TotalMilliseconds;

That returns 1298912400000 for me but they say it should be 1298930400000 so what am I doing wrong?

Perhaps this is a question for the authors of the web service you're using? — Oliver Charlesworth, Aug 19 '11 at 11:56
Yeah unfortunately my emails and phone calls have gone unanswered. — Jimmy D, Aug 19 '11 at 11:57
@EscobarCeaser Their web GUI is compensating for your timezone and DST settings of your locale. So the result you get from the website differs from the result you get from your own code, which is UTC. — Kyle Pittman, Feb 03 '16 at 18:53

score 3 · Accepted Answer · answered Aug 19 '11 at 11:56

3

They are using milliseconds, and you probably aren't compensating for timezone.

answered Aug 19 '11 at 11:56

Andreas Eriksson

8,979
8
47
65

Hhhmm... Gonna try milliseconds and report back. Stay tuned. – Jimmy D Aug 19 '11 at 11:57
Ok. I think you're definitely right about the milliseconds part because when I convert my TimeSpan to total milliseconds the number is 3 zeros longer. But I'm using UTC and I don't know why they wouldn't be. Do you know how I might handle this? – Jimmy D Aug 19 '11 at 12:04
Actually, having read up on it, getTime() is actually supposed to always return milliseconds since Jan 1 1970 in UTC. Why they appear to be adding 6 hours is anyone's guess. – Andreas Eriksson Aug 19 '11 at 12:09
Do you have any sort of API documentation for said service on hand? – Andreas Eriksson Aug 19 '11 at 12:15

Unix time oddity, or something else?

1 Answers1