#johnm-unix-timestamp

1 messages · Page 1 of 1 (latest)

foggy lindenBOT
thin narwhal
#

What is the exact timestamp you use? We do use the unix epoch and second ticks

wild merlin
#

I need to add, this was happening when a developer in Nepal was running the code

#

this is the java code

#

Long epochSecond = LocalDateTime.now().toEpochSecond(ZoneOffset.UTC);

thin narwhal
#

Can you print out the value of epochSecond when you run that code?

wild merlin
#

this is what this op code does

#

Converts this date-time to the number of seconds from the epoch of 1970-01-01T00:00:00Z.
This combines this local date-time and the specified offset to calculate the epoch-second value, which is the number of elapsed seconds from 1970-01-01T00:00:00Z. Instants on the time-line after the epoch are positive, earlier are negative.
This default implementation calculates from the epoch-day of the date and the second-of-day of the time.

#

I am not in a position to give an actual example at this time.

thin narwhal
#

I get what it is going for but still think it would be helpful to print out the exact value that you get here. It really should be the epoch plus however many seconds since then

#

If we told you the timestamp was in the future, it is likely either in the future, or you are using a test clock that is frozen at a time in the past

wild merlin
#

my main question is that getting should the time zone matter ?

#

My developer in in a time zone 11 hours ahead of EST which is 5 hours ahead of UTC

#

He says he has fixed it... I just want to make sure it is the correct solution

#

does Stripe have an official time zone... I know you have customers world wide

brave pier
#

@wild merlin everything is always in UTC. We only handle unix timestamps so there's never a timezone issue

#

johnm-unix-timestamp

wild merlin
#

Ok, then it was a code issue then. I thought UTC was correct. Thanks