Oddbean new post about | logout
▲ ▼
franzap | 1 months ago (raw) | root | parent | reply | flag 
 This is interesting. Timestamp as in local timestamp when that post-EOSE event arrived? Aren't there discrepancies/timezone issues between client and event signing times?
▲ ▼
franzap | 1 months ago (raw) | root | parent | reply | flag 
 Clarification: I'm sending a REQ with a `#d` set of app IDs to check for updates.

But I can't include one `since` for each app ID in one query, so I have two options: 
 - use the oldest `created_at` of the app ID set - but if one of the apps is quite old, I reap almost no caching benefit
 - send one filter per app - this would work well, but I could have potentially 100s of apps to check which translates into 100s of backend requests for one check

If the relay sent a timestamp, I could use that as the `since` for the next request. The only drawback is it wouldn't catch any back-dated apps, but that is uncommon.
▲ ▼
Vitor Pamplona | 1 months ago (raw) | root | parent | reply | flag 
 There is no discrepancy. Most apps need to be in sync with NTP just to use the regular web. It works quite well for amethyst.
▲ ▼
franzap | 1 months ago (raw) | root | parent | reply | flag 
 Nice. Are all created_at supposed to be in UTC?
▲ ▼
Vitor Pamplona | 1 months ago (raw) | root | parent | reply | flag 
 No need to convert timezones. Your unix Timestamp and the servers Timestamp are the same regardless where you are.
▲ ▼
franzap | 1 months ago (raw) | root | parent | reply | flag 
 Oh, right, unix timestamps are always UTC. Thanks man!
▲ ▼
mleku | 1 months ago (raw) | root | parent | reply | flag 
 android and linux use UTC in their real time clocks but windows uses the local time and if that's wrong it is wrong

windows is wrong, the internet is international