1. 2

    What is a “Programming HP and MP”?

    1. 3

      Assuming its “Health Points” and “Mana Points”. In fantasy role playing games, characters would consume elixirs to restore theses.

      1. 2

        consume elixirs to restore theses.

        Now I’m imagining a graduate-school based RPG where you suffer academic death if a dragon eats your thesis.

        1. 2

          Woops.

          Now I’m imagining a graduate-school based RPG where you suffer academic death if a dragon eats your thesis.

          Assuming that Persona or Disgaea would fold that in at some point.

    1. 3

      The post seems to imply that the scheduling problems mentioned are because the underlying systems' timezone data was out of date. However, for that to be the case, the scheduled meeting (or game) had to take place where the time zone rules somewhat recently changed and also during the period where the rules were previously wrong. I find that highly unlikely.

      More likely is the software simply calculated the wrong time, either because it thought the user’s current location was somewhere else (e.g., the user is in PST, but the software thought they were in MST), or there’s simply a bug. This means that the remedy described (automated timezone data updates) won’t really help.

      1. 1

        However, for that to be the case, the scheduled meeting (or game) had to take place where the time zone rules somewhat recently changed and also during the period where the rules were previously wrong.

        It is true that the time zone rules somewhat recently changed. The rules were not previously “wrong”.

        Look at this screenshot: http://imgur.com/NolBQNk Facebook shows 18:00 and 19:00 for the same event. It would work correctly if Facebook’s timezone data was up to date.

        1. 1

          Consider that the software responsible for storing and scheduling the event may well be different from the software (and device!) viewing the event. Every part of the system has to be using the same tzdata.

          1. 1

            Sure, but like @tedu says, how come 7 of 8 players (presumably living in the same time zone) showed up on time? And again, did the time zone data change for that particular time zone during the period of that particular game that was scheduled that could possibly have caused a scheduling error for only one player? It seems much more likely that it’s the more typical errors in taking whatever time was stored (hopefully UTC) and processing it correctly (translating it to the user’s timezone).

            1. 1

              Facebook devs don’t see the issue because they mostly sit in a place where the last time zone data change was almost 10 years ago. See my response to tedu about why most people were on time.

              Facebook shows the time for an event in various ways apparently. It seems to sometime show the time entered (the correct time) and sometimes not. This is on the website. There is also the issue of mobile Facebook apps that probably gets timezone info from a phone.

              So usually most people will see the correct time. But because the tzdata is out of date, some places it was wrong.

              (hopefully UTC)

              I wrote this about why future events should not always be stored in UTC: http://www.creativedeletion.com/2015/03/19/persisting_future_datetimes.html In this case, saving the local time plus timezone identifier would have been better than UTC. Facebook could simply show the entered local time without changing it.

              And using up to date tzdata plus the timezone identifier would make it possible to calculate when that time was compared to UTC or any other timezone. This would be useful for the reminders.

        1. 4

          Lots of assumptions/assertions without a lot of evidence. How did 7 of 8 players show up at the correct time? Does Facebook only have out of date time zones on some of its servers? Having different inconsistent data would be a much larger problem, and even undercuts authors thesis. They got the time zone right on 7 servers, so clearly they’re trying to update it.

          1. 4

            Haha, I wrote the article and I was there.

            The rest of the players showed up at the correct time because most are regulars and the game is always at 20:00. The guy who was late was a new guy and a foreigner. So he did not know to ignore the buggy Facebook behavior.

            If you want some evidence, look at this: http://imgur.com/NolBQNk Facebook some places shows the correct time/offset, some places not.

            1. 2

              That answers that - I believed the article, but I had wondered how it happened. :)

          1. 1

            I had my laptop set to UTC for a while (OSX won’t let you do that directly, you have to pick Reykjavík time). This messed up many websites which requested local time and compared it to a global database. The most annoying was Yelp, it would consider every restaurant closed for dinner since 7pm PDT is 2am UTC…

            1. 1

              So they assume the visitor is browsing from devise set to the same timezone as the restaurant. That is a big assumption.

              1. 1

                But a reasonable one for most devices. If it is not the case, then the user is typically aware that their clock is wrong.

                The only case I can think of where that might not be the case, and it is when yelping on a laptop in a different timezone than usual.

                1. 1

                  What if you live close to a time zone border? Maybe the restaurant is a 10 minute trip away, but in another timezone. What if you are talking on the phone with someone in another timezone and they want you to help find an open restaurant?

                  1. 1

                    If I live close to a timezone border, Yelp should know that the restaurants I’m looking at are +-1 and do the right thing. I don’t know if it does. So I’d have my timezone set to (for example) GMT-5 and lived right next to GMT-6 (Monticello, KY used to actually be divided between the two), then if I look at a restaurant that is on the GMT-6 from GMT-5, Yelp should do the math. It knows what timezone the restaurant is in, and what timezone I am in.

                    If you’re helping someone find something over the phone, that’s an extreme edge case. The pattern I’d use there is to have them look it up based on name (which they probably will anyway just to see if the menu looks appetizing).

            1. 1
              {:ok, 7200, 0}
              # 7200 seconds is two hours
              

              It most certainly is not! At least, not always. It could be 2:00:00, 1:59:60, or even 2:00:01 if we ever end up doing a negative leap second.

              I’d imagine given the author’s work on this topic that their code correctly handles positive and even negative leap seconds. But I get nervous when people reference an hour in terms of 3600 seconds.

              1. 2

                That function ignores leap seconds. The documentation states this. The example is in March and there won’t be a leap second in March. They are either at the end of June or December.

                The library does have limited leap second support. I have thought about supporting leap seconds in more functions. But it is not the highest priority.

                One big issue is that most operating systems do not support leap seconds. Because of the upcoming leap second I have tried to set the time to just before the leap second on a Ubuntu virtual server. And run some tests. But it if you simply run date, it just isn’t supported. It is not supported by the Erlang calendar module either.

                In most cases leap seconds are not as big a problem as time zones and DST. The risk of being off by 1 second once every 18 months is not as bad as being off by 3600+ seconds for long periods of time.

                As for negative leap seconds they have not happened yet. If the earth starts to slow down that much I will have to change some code :)

              1. 1

                If you invest $10 in a company and it pays a dividend of $1 for 20 years and then goes out of business, you have made money on the investment without ever selling the shares.

                Only companies that don’t actually turn a profit really need to IPO or be acquired.

                1. 8

                  Just to throw a nuance into this (because, you know… time zones), when you do this you’ll probably run into the situation of having people enter times that don’t exist because of daylight savings, or times that are ambiguous because they occur twice. Kelecto’s approach seems alright, but if you are planning on doing something like this you may need to consider those edge cases, and how you acquire the offset.

                  I have worked on some scheduling-heavy applications and it’s been impressive how inevitable it is to run into those sorts of situations. Lay people will never appreciate how complicated, yet deceptively simple representing and working with time is.

                  1. 3

                    Blog poster here. Yes, ambiguous/non-existing datetimes are things that should be considered. I am glad that I’m not the only one that realize that these can be real issues!

                    Fortunately I have thought of that too. If you try to create a DateTime that does not exist you get an error. If you try to create a DateTime that is ambiguous, the response is tagged with :ambiguous and you get a struct with the two possibilities. You can then choose what to do - ask the user which one he/she wants or maybe you want to just choose one of them based on some kind of algorithm or default.

                    Specifics are in the Kalends docs: http://hexdocs.pm/kalends/Kalends.DateTime.html#from_erl/3

                    Kalends is the main datetime library that I made. Kalecto is an adapter for Kalends for saving datetimes, dates and times to a database with the Ecto library.