5 ms·

I've noticed this behavior with a lot of services. I can only chalk it up to something like clock drift between the processing node and the database server. I

by i336_ 9y ago

I've noticed this behavior with a lot of services. I can only chalk it up to something like clock drift between the processing node and the database server. Irritatingly I can't remember which site it was but I posted something somewhere a couple days ago and immediately after hitting enter the site marked what I'd said as submitted "a few seconds from now". I never fail to be amused that the fuzzy time library being used has code specifically designed to handle this edge case scenario. :D

toomuchtodo 9y ago
Message queues and eventual consistency. Unless your request requires something "atomicy", 200/201 response should be a sign of "got the message, will get to work on it when we can".
- peterwwillis 9y ago
  201 is "request has been fulfilled, resource has been created". It is explicitly not "we will get to it when we can". You are thinking of 202, "request has been accepted for processing", for asynchronous request processing.
  - toomuchtodo 9y ago
    I assure you, 201 is used all the time to say something has been done when it's only been queued, regardless of what the RFC says. This is based on real world integration experience. Http response status codes rarely align with RFC guidelines.
    - peterwwillis 9y ago
      A lot of people back up to tape and never test the tapes, too. Doesn't mean bad practice should be expected.
      - toomuchtodo 9y ago
        Disagree. Plan defensively.
epicide 9y ago
I don't think it's really an edge case. Probably one of the main uses, actually. Sure, if you use it to show comment age, you shouldn't ever see it, but I'm sure they fully support using it for countdowns, too. EDIT: it's the 4th example under relative time for Moment.js (https://momentjs.com/ https://momentjs.com/).
- i336_ 9y ago
  I can totally agree about relative timestamping in both directions (past+future) - my argument is more about the UX of situations where you're canonically referring to a past event. So as not to spam with my reply to a similar comment, I'll link it: https://news.ycombinator.com/item?id=14452335 https://news.ycombinator.com/item?id=14452335
Piskvorrr 9y ago
Actually, most of the "relative time" JS libraries can be used for countdown as well ("this event is scheduled in two hours"). Accidentally getting a timestamp that's supposed to be in the past shouldn't break it :)
- i336_ 9y ago
  Very true. I just think there should be an intent argument specifiable to the library to indicate that the duration in question refers to an event that has happened in the past. In such a scenario, the library should mark the duration as happening "just now" and possibly flag a warning or raise an exception. The reason I say this is that, humanly speaking, "Your message was sent 23 seconds from now" is amusing at best to developers who know what's happening (negative time delta) and linguistically confusing to general users ("was sent" vs "from now").
yeukhon 9y ago
Git timestamp can be set with different timezone so technically GitHub can analzye the timestamp (which they do) and compare with the actual clock of timezone. There's only a small problem though: the latency from the clock check server must be low otherwise we would be 1 second ahead by the time we get response and then another second or two after webpage render. So from a UX we should simply discount time drift +-5 seconds simply says "blah blah just now" and anything larger might warrant as a warning to the author (Github can reject the commit and ask for confirmation). Although re-editing commit is a hassle for changing timestamp. It's more of a "please make sure you computer time is synced next time."
- i336_ 9y ago
  Wow, interesting. This info is definitely filed away, thanks. I don't quite remember but I think I might've been commenting on something on GitHub when I saw the time glitch. Initially for a moment I thought "why not just have OCD local NTP tracking?" but then I realized that time glitching around (even at the millisecond level) can be disastrous. One way to solve this is to obsess about keeping up to date with NTP, but instead of updating the time, update a global reference to the offset. Then your time server is simply (system date)+-(saved offset), which should be super fast. And of course this can run on the node generating the HTML.
  - yeukhon 9y ago
    If you look at "man git-commit-tree" While parent object ids are provided on the command line, author and committer information is taken from the following environment variables, if set: GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL GIT_AUTHOR_DATE GIT_COMMITTER_NAME GIT_COMMITTER_EMAIL GIT_COMMITTER_DATE (nb "<", ">" and "\n"s are stripped) In case (some of) these environment variables are not set, the information is taken from the configuration items user.name and user.email, or, if not present, the environment variable EMAIL, or, if that is not set, system user name and the hostname used for outgoing mail (taken from /etc/mailname and falling back to the fully qualified hostname when that file does not exist). A commit comment is read from stdin. If a changelog entry is not provided via "<" redirection, git commit-tree will just wait for one to be entered and terminated with ^D. DATE FORMATS The GIT_AUTHOR_DATE, GIT_COMMITTER_DATE environment variables support the following date formats: Git internal format It is <unix timestamp> <time zone offset>, where <unix timestamp> is the number of seconds since the UNIX epoch. <time zone offset> is a positive or negative offset from UTC. For example CET (which is 2 hours ahead UTC) is +0200. RFC 2822 The standard email format as described by RFC 2822, for example Thu, 07 Apr 2005 22:13:13 +0200. ISO 8601 Time and date specified by the ISO 8601 standard, for example 2005-04-07T22:13:13. The parser accepts a space instead of the T character as well. Note In addition, the date part is accepted in the following formats: YYYY.MM.DD, MM/DD/YYYY and DD.MM.YYYY. Edit see this repo and screenshot: * https://github.com/yeukhon/demos/commits/master/git-date https://github.com/yeukhon/demos/commits/master/git-date * https://github.com/yeukhon/demos/blame/a9fc9dfe6d35c5ffe14af9139a9b0a124ab60658/git-date/foo.txt https://github.com/yeukhon/demos/blame/a9fc9dfe6d35c5ffe14af... * https://github.com/yeukhon/demos/commits/a9fc9dfe6d35c5ffe14af9139a9b0a124ab60658/git-date/foo.txt https://github.com/yeukhon/demos/commits/a9fc9dfe6d35c5ffe14... You see I got a 3 minute (using local time) and then 4 hours ago because I set the timestamp manually in the most recent commits. So yes you can set time in the future / past.

by i336_ 9y ago

toomuchtodo 9y ago

Message queues and eventual consistency. Unless your request requires something "atomicy", 200/201 response should be a sign of "got the message, will get to work on it when we can".

peterwwillis 9y ago
201 is "request has been fulfilled, resource has been created". It is explicitly not "we will get to it when we can". You are thinking of 202, "request has been accepted for processing", for asynchronous request processing.
- toomuchtodo 9y ago
  I assure you, 201 is used all the time to say something has been done when it's only been queued, regardless of what the RFC says. This is based on real world integration experience. Http response status codes rarely align with RFC guidelines.
  - peterwwillis 9y ago
    A lot of people back up to tape and never test the tapes, too. Doesn't mean bad practice should be expected.
    - toomuchtodo 9y ago
      Disagree. Plan defensively.

epicide 9y ago

I don't think it's really an edge case. Probably one of the main uses, actually. Sure, if you use it to show comment age, you shouldn't ever see it, but I'm sure they fully support using it for countdowns, too. EDIT: it's the 4th example under relative time for Moment.js (https://momentjs.com/ https://momentjs.com/).

i336_ 9y ago
I can totally agree about relative timestamping in both directions (past+future) - my argument is more about the UX of situations where you're canonically referring to a past event. So as not to spam with my reply to a similar comment, I'll link it: https://news.ycombinator.com/item?id=14452335 https://news.ycombinator.com/item?id=14452335

Piskvorrr 9y ago

Actually, most of the "relative time" JS libraries can be used for countdown as well ("this event is scheduled in two hours"). Accidentally getting a timestamp that's supposed to be in the past shouldn't break it :)

i336_ 9y ago
Very true. I just think there should be an intent argument specifiable to the library to indicate that the duration in question refers to an event that has happened in the past. In such a scenario, the library should mark the duration as happening "just now" and possibly flag a warning or raise an exception. The reason I say this is that, humanly speaking, "Your message was sent 23 seconds from now" is amusing at best to developers who know what's happening (negative time delta) and linguistically confusing to general users ("was sent" vs "from now").

yeukhon 9y ago

Git timestamp can be set with different timezone so technically GitHub can analzye the timestamp (which they do) and compare with the actual clock of timezone. There's only a small problem though: the latency from the clock check server must be low otherwise we would be 1 second ahead by the time we get response and then another second or two after webpage render. So from a UX we should simply discount time drift +-5 seconds simply says "blah blah just now" and anything larger might warrant as a warning to the author (Github can reject the commit and ask for confirmation). Although re-editing commit is a hassle for changing timestamp. It's more of a "please make sure you computer time is synced next time."

i336_ 9y ago
Wow, interesting. This info is definitely filed away, thanks. I don't quite remember but I think I might've been commenting on something on GitHub when I saw the time glitch. Initially for a moment I thought "why not just have OCD local NTP tracking?" but then I realized that time glitching around (even at the millisecond level) can be disastrous. One way to solve this is to obsess about keeping up to date with NTP, but instead of updating the time, update a global reference to the offset. Then your time server is simply (system date)+-(saved offset), which should be super fast. And of course this can run on the node generating the HTML.
- yeukhon 9y ago
  If you look at "man git-commit-tree" While parent object ids are provided on the command line, author and committer information is taken from the following environment variables, if set: GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL GIT_AUTHOR_DATE GIT_COMMITTER_NAME GIT_COMMITTER_EMAIL GIT_COMMITTER_DATE (nb "<", ">" and "\n"s are stripped) In case (some of) these environment variables are not set, the information is taken from the configuration items user.name and user.email, or, if not present, the environment variable EMAIL, or, if that is not set, system user name and the hostname used for outgoing mail (taken from /etc/mailname and falling back to the fully qualified hostname when that file does not exist). A commit comment is read from stdin. If a changelog entry is not provided via "<" redirection, git commit-tree will just wait for one to be entered and terminated with ^D. DATE FORMATS The GIT_AUTHOR_DATE, GIT_COMMITTER_DATE environment variables support the following date formats: Git internal format It is <unix timestamp> <time zone offset>, where <unix timestamp> is the number of seconds since the UNIX epoch. <time zone offset> is a positive or negative offset from UTC. For example CET (which is 2 hours ahead UTC) is +0200. RFC 2822 The standard email format as described by RFC 2822, for example Thu, 07 Apr 2005 22:13:13 +0200. ISO 8601 Time and date specified by the ISO 8601 standard, for example 2005-04-07T22:13:13. The parser accepts a space instead of the T character as well. Note In addition, the date part is accepted in the following formats: YYYY.MM.DD, MM/DD/YYYY and DD.MM.YYYY. Edit see this repo and screenshot: * https://github.com/yeukhon/demos/commits/master/git-date https://github.com/yeukhon/demos/commits/master/git-date * https://github.com/yeukhon/demos/blame/a9fc9dfe6d35c5ffe14af9139a9b0a124ab60658/git-date/foo.txt https://github.com/yeukhon/demos/blame/a9fc9dfe6d35c5ffe14af... * https://github.com/yeukhon/demos/commits/a9fc9dfe6d35c5ffe14af9139a9b0a124ab60658/git-date/foo.txt https://github.com/yeukhon/demos/commits/a9fc9dfe6d35c5ffe14... You see I got a 3 minute (using local time) and then 4 hours ago because I set the timestamp manually in the most recent commits. So yes you can set time in the future / past.