Jump to content

LostKobrakai

PW-Moderators
  • Content Count

    4,848
  • Joined

  • Last visited

  • Days Won

    98

LostKobrakai last won the day on February 19 2019

LostKobrakai had the most liked content!

Community Reputation

5,036 Excellent

6 Followers

About LostKobrakai

  • Rank
    Hero Member
  • Birthday 11/29/1991

Contact Methods

  • Website URL
    http://www.kobrakai.de

Profile Information

  • Gender
    Male
  • Location
    Munich, Germany

Recent Profile Visitors

18,624 profile views
  1. That sounds great. I'm mostly using elixir nowadays and they have a language server implementation, as most editors don't bother implementing it by default.
  2. I'll certainly take a look at it once it's in beta, but I'm wondering if you can tell us something about which languages it actually supports and if it uses something like language server protocol? I used coda ages ago and I liked their batteries included approach at the time.
  3. Basically any calendar application. If I have an appointment in a year at 10 o'clock, then I want to be reminded for it being at 10 o'clock. People usually don't care about the absolute time in such cases. Any change in wall time would be considered incorrect. On the other hand you're correct. If e.g. a job is supposed to run a fixed amount of time then a change in timezone definition shouldn't make it run longer.
  4. So the key information here is that the offsets of timezones are not fixed for eternity. There are databases you can download to your OS or e.g. from groups like IANA, which hold information about which offset a certain timezone was exposed to at which period of time. And those databases are updated about a handful of times a year (but not each time for actual new rulings). A good example for actual changes is the EU, which is currently starting the process of migrating away from switching to/from DST. Generally you're mostly fine for past datetimes, but the farther you're in the future the more likely it becomes the offset you expect the timezone to have at the time could change until that time. If you convert 12.12.2030 10:00 for Europe/Berlin to 12.12.2030 9:00 UTC with the current offset of +1 in the winter and we go forward 10 years it's not clear if you get back 12.12.2030 10:00 for Europe/Berlin. The EU's efforts to remove DST might have been fruitful and Europe/Berlin is now at +2 offset all year (all year DST). So you take the db value of 12.12.2030 9:00 UTC, you add the offset for Europe/Berlin, which then is +2 and you get 12.12.2030 11:00 for Europe/Berlin. The UTC datetime was preserved, but the "wall time" wasn't – wall time being the time I see on the clock here in my office. You might be an hour late to some important appointment. You can ignore all the above if you never convert between timezones, which as far as I can see, is what processwire is doing. 12.12.2030 10:00 for Europe/Berlin will still be 12.12.2030 10:00 for Europe/Berlin when read from the db in 10 years. Essentially the wall time is preserved. This comes at the expense of absolute distance of time between two datetimes being subject to change and not being able to have absolute ordering for dates of different timezones. The latter is not a problem if the whole system just uses one timezone. This is why I said it's important to know what you care for. The absolute time passing by until a datetime or the actual time on the wall on a certain day. If you want UTC timestamps in your db, but not give up preserving the correct walltime you'll need to store more information in the db besides the utc timestamp to be able to react to changes like I described.
  5. There's one more problem. While the UTC time stays the same in the absolute term the wall time shown to the user might change. Say today someone enters a date in the future at 11 o'clock their timezone. At midnight an OS updates happen and a new timezone db is installed. The next day the time might be 10 o'clock that day. For dates - especially in the future - you'll need to be aware what matters to your users. Walltime or absolute time (UTC). Because the difference (the utc and std offset) are subject to change. If you want to compare datetimes in the db though all datetimes all need to be in the same timezone (or really UTC), so if that's a need it gets complex quickly because you need to store timezone and offset at time of writing to the db as well, besides the UTC timestamp. This is the only way to later come back to the intended wall time and being able to detect changes in timezone definition, which might result in a different walltime.
  6. Python has one big advantage over PHP, which people might or might not care about: It‘s widely used for devops tooling because it‘s preinstalled on so many systems and it‘s growing super fast in the space of ML/AI/Science based computing because of it‘s bindings to fast low level C code while still writing python on top. If you care about those things or you want to do them as well, but not introduce a mix of technology, then sure python is a great solution. If not I don‘t see any reason to switch from whatever one is using right now.
  7. Personally I‘d first look into using an existing solution for gathering the data (I‘ve had good experience with https://feed2go.com/de/) and just create a way to bring back data into existing systems later. Webapps have the problem that their storage while available at times is not ensured to stick around. If e.g. the device disk space runs low it might be cleared out. Also you‘re already in the realms of a fully client side app, so you could just embrace it.
  8. The biggest hurdle of timezones is actually in handling "the future". Timezone rules are in constant fluctuation (be it error corrections or actual changes the IANA timezone database changes a few times a year: https://www.iana.org/time-zones). One prominent example is the EU right now, where DST was ruled to be eliminated in the near future giving each country the option to choose if they want to stay on DST or non-DST offset. Therefore to store a point in time (in the future) you at best store not just a datetime/timestamp, but a timestamp as well as the source timezone and used offset. This allows you to detect if the offset of a timezone did change between the time is was stored to the db until the time of retrieval. Otherwise changes in timezone definition might lead to incorrect results (someone being at a place at 11:00 when the time was supposed to be 10:00 wall time). This blog has a few posts on the topic, even if they're not in php: http://www.creativedeletion.com/2015/03/19/persisting_future_datetimes.html Edit: You can ignore changes in timezone definition by storing datetimes in their source timezone, but this won't let you easily compare multiple values in the db. I've some more interesting things on the topic to share. If you're working with intervals I highly suggest using Allen's Interval Algebra as well as watch this talk by Eric Evans:
  9. The session cookie is unique to a browser session, and seldom used without you holding more information about the user, which by my impression does fall in the definition of personal data how gdpr defines it: https://gdpr-info.eu/art-4-gdpr/ But as I said the gdpr doesn‘t explicitly demand banners. It demands that users are informed about the usage of the data (privacy documents).
  10. The GDPR doesn't actually handle cookies specifically. GDPR is about processing personal data. A cookie is processed by a webserver when a user accesses your website, so GDPR is applicable IF there is personal data involved in regards to the cookie. Even a simple session cookie is personal data, because it identifies a certain browser session, which in turn likely identifies a person. There are a few things GDPR demands you to provide to users in such a case, like what the data is used for (Art. 13/14) and it needs to have a legitimate reason (Art. 6) for you to be allowed to do so. This is even more complex if it's not a cookie set by your website, but by a third party. There it's the shared responsibility between your and the third party that everything is handled correctly. This is usually done with DPA (data processing agreement) which is a binding contract where both parties essentially guarantee each other GDPR compliance. The GDPR gives users the right to deny consent wherever you cannot use Art. 6 1.f) as legitimate reason. Therefore cookie-banners with the option to not have certain cookies set. The GDPR also says you may not auto opt people into giving consent, therefore the default for optional cookies should be unset. Besides the GDPR there's afaik a law in Germany for cookies specifically, which has been the kinda predecessor for the long overdue EU wide ePrivacy directive. I'm not as well versed with this one. It was essentially the law, which started all the cookie banner stuff.
  11. Most of the stuff in the .htaccess is actually not needed to run processwire, but to prevent access to places nobody should snoop around. This only becomes a problem though if there is indeed a file in such a location, which would be directly accessed. In common usage those things rarely pop up, because who tries to read e.g. /site/config.php or even non php files of the installation.
  12. Why do you need to post values, which are no longer editable though? Should this not work just fine with the field disabled / not rendered as inoutfield?
  13. The downside would be the need to ship a list of languages/iso codes with the processwire core. I guess with weekly releases it's not to much of a pain though to require a fresh release once there's a change in that list.
  14. First of all ISO 3166 is for countries, not languages – there are countries like switzerland, which has 4 official languages. ISO 639 is what we would need. But ProcessWire doesn't care about that. You could be needing Globish, which doesn't have an iso code. So the iso code should always be optional anyways. This difficulty is exactly why I made my PR not rely on an automatic mapping, but simply let users decide which translation to import into which language of the system. Once processwire might add an field for iso codes to the languages template it's an easy addition to detect matching codes and suggest imports to the user automatically.
×
×
  • Create New...