exported files --> wrong timestamp

luke_jaeger100

When I export a file (eg downloading an .stl) I notice that the file has a timestamp 5 hours in the future. In other words it seems to be referenced to GMT + 0. Can that be changed?

luke_jaeger100

anyone else able to reproduce this problem? is it just me?

lougallo

@luke_jaeger100 What OS do you see it this way?

billy2

luke-

it's the internet. 

The time needs to be computed at the client not the server. Your server is more than likely 5 hours different than you. Most internet programs will report back the server time. The client has to pass your time back to the server to get your real time and most people don't hassle with the client's time.

What' time is it? There's not an easy answer on the internet.

henry_feldman

billy2 said:

What' time is it? There's not an easy answer on the internet.

Even trickier, this is a cloud solution so I imagine servers are distributed around the globe. Do all the servers in the cloud obey one time standard (say US-EST since that is where OnShape headquarters is)? If so that would solve the time-order of features problem, but create the issue above for people out of that time zone. However if you use local time zone, someone in indonesia editing a file simultaneously with someone in new york could create all sorts of crazy time-travel problems with feature-order, since they are working "in the future".

Or we can just adopt Alan Jackson/Jimmy Buffet's line: "It's 5 o'clock somewhere..."

billy2

Jimmy Buffet should time. I'm up with that.

luke_jaeger100

I'm in New England, GMT -5, about 100 miles from the OnShape headquarters. I would assume their nearest server is not in GMT + 0 !
I noticed this problem on OS X.  

luke_jaeger100

henry_feldman said:

billy2 said:

What' time is it? There's not an easy answer on the internet.

Even trickier, this is a cloud solution so I imagine servers are distributed around the globe. Do all the servers in the cloud obey one time standard (say US-EST since that is where OnShape headquarters is)? If so that would solve the time-order of features problem, but create the issue above for people out of that time zone. However if you use local time zone, someone in indonesia editing a file simultaneously with someone in new york could create all sorts of crazy time-travel problems with feature-order, since they are working "in the future".

Or we can just adopt Alan Jackson/Jimmy Buffet's line: "It's 5 o'clock somewhere..."

There actually is an easy answer - UTC - and I can't imagine the folks who designed OnShape would be dumb enough to use the client-local TZ as an absolute reference for timestamps. Otherwise, I could modify my Onshape file near the far western edge of some TZ (say in Sandford, IN), drive a few minutes to Illinois and log back in, and the server would think I'd traveled back in time to before the file was last saved.

billy2

Maybe timestamps aren't a reliable metric? 

I just asked my server what time it was. It's in San Francisco and I'm in San Diego, luckily the time was correct.

When I write cloud code, I send the client's time back to the server in the initiation of the web page. This means the correct time for me is the user's time. Is this right?

henry_feldman

luke_jaeger100 said:

I'm in New England, GMT -5, about 100 miles from the OnShape headquarters. I would assume their nearest server is not in GMT + 0 !
I noticed this problem on OS X.  

On the latest version of OS X and only 3mi from OnShape's headquarters using Safari, just tried it, and at least for me it is accurate within the minute (I probably downloaded across the minute boundary)

luke_jaeger100

Just noticed this is still happening. Strange eh?

luke_jaeger100

luke_jaeger100

am I really the only person having this issue?
It's not critical but it sure is weird.

Jake_Rosenfeld

@luke_jaeger100
Where are you in the world? Is the time on your computer correct? Is the time zone correct in your system settings?

@john_rousseau FYI

john_rousseau

The HTTPS download of the file does not provide time information. Your browser and OS are coming up with the date that they set on the file. I just downloaded a file and the timestamp is "now" for my local machine. Your browser may be making some assumptions about where Onshape servers are and adjusting the timezone appropriately. My guess is that there's a configuration "disagreement" between your browser and Finder.

luke_jaeger100

Jake_Rosenfeld said:

@luke_jaeger100
Where are you in the world? Is the time on your computer correct? Is the time zone correct in your system settings?

@john_rousseau FYI

I'm in western massachusetts, and my TZ and clock are correct.

luke_jaeger100

john_rousseau said:

The HTTPS download of the file does not provide time information. Your browser and OS are coming up with the date that they set on the file. I just downloaded a file and the timestamp is "now" for my local machine. Your browser may be making some assumptions about where Onshape servers are and adjusting the timezone appropriately. My guess is that there's a configuration "disagreement" between your browser and Finder.

What would that look like? I'm using Chrome v. 64.0.3282.167 on Mac OS 10.12.6 . Not sure where such a configuration would even come from.

luke_jaeger100

OK, this is interesting. It's 11:33 am here in Massachusetts. 

• I download two parts as a .zip file --> the timestamp on the .zip is correct.
• I download a single .stl file --> the timestamp is correct.
• I decompress the downloaded .zip file --> the files inside have a timestamp 5 hours in the future (4:33 pm)
• This doesn't happen with other .zip files on my hard drive.
• If I 'touch' the .zip file from OnShape to update the timestamp to now, then decompress it again, same result. So the wrong timestamp on the compressed files isn't somehow being referenced to the timestamp on the .zip archive itself, or otherwise generated on the client side.

Is the .zip compression happening on a different server that is set to GMT + 0 ?

john_rousseau

Interesting. Yes, that is exactly what is happening. Your browser controls the timestamp of the zip file but we do control the timestamps on the contents of the zip file. All of our servers around the globe are set to UTC.

This will be the same behavior as any other zip file you get from another source. Looking up the ZIP spec, I see:

The ZIP format has no notion of time zone, so timestamps are only meaningful if it is known what time zone they were created in.

I don't think there is much we are going to be able to do about this. Sorry for the hassle. I don't think artificially changing the timestamp to be in the past for all users would be an improvement.

luke_jaeger100

John, thanks for the info. Do your servers know what time zone I'm in? It would be fairly trivial to calculate the time zone offset and touch the files with that modification time before zipping. For me this has mainly been just a weird annoyance, but I can imagine situations where incorrectly datestamped files could screw up a workflow pretty royallly!

matt_denardo

For what it's worth, I just noticed this when exporting a Parasolid (5 hours in the future). However, an exported PDF from a drawing in the same document has the correct time.