Came here to add that. I saw it as kind of a joke (and there is a Star Trekky 90's techno-optimism to the whole thing that I miss now) due to the Pauly Shore parody of it, and so I went on a whim when I was in town. It's actually an impressive work of engineering in its way, and used to study ecosystems to this day although it is no longer sealed. I'd recommend a visit to anyone.
Also the tooling has improved a lot, making functional programming accessible to people outside of academia. A good example of this is Elixir/Phoenix. Ruby “wowed” everyone with their “Create a Blog in 15 min”. Now they did the same with “Create a real time twitter in 15 min”.
Co-founder and CEO Niklas Zennström is a Swede and so Skype always had a clear connection to Sweden. But yes, Estonia also deserves a lot of credit for Skype of course, as the development work was mostly done there.
A lot of the credit? Estonia is 99% of Skype. There's a reason their tech ecosystem (which is more impressive than Sweden's) is called the "Skype Mafia"
Anyway, my point is that whether correctly or incorrectly, that thanks to Zennström, many people do associate Skype also with Sweden, and he acted as an early role model for other future startup entrepreneurs from Sweden.
Take in consideration to not use floats for money. Use a `decimal` data format. I'd also advice against using javascript since it has problems dealing with big numbers. There are libraries of course to handle that.
Just if you use JS make sure to google about how to do money calculations accurately.
I see this statement a lot and would like to see it better illustrated or quantified.
I worked at a place that used doubles and there was no fallout. Also when dealing with very small quantities, fixed point might not work so well either.
Personally, as a general rule I use integer's and convert for display only (as mentioned in the above SO post). This removes the accuracy issue and works in every programming language that is in common use today (at least that I know of). I even do this in Postgres (and other DB's) which keeps everything consistent and removes the chance a driver between the DB and client jacks up the decimal conversion.
Primarily, forgetting to divide by 100 is an obvious error and easy to debug when compared to a database driver/interface being updated that tweaks the decimal conversion which is much more subtle and hard to debug. Your point is valid though in a situation where you only use one database system and one development language that both support decimal properly it isn't "bad" to use decimal, thought I'd still personally use integer for future proofing the data.
Secondly (and why I'd still use integers regardless), every language supports integers and division, not every language can support decimals properly or consistently. So for guaranteed accuracy it is best to use integers. Web being so javascript driven is a primary consideration here.
IMO this is something similar to dealing with time in distributed/complex systems. Sure there are types in postgres (and most DB's) that handles timezone, but it still is best to use UTC for everything stored in data and only do timezone conversions at the display layer when necessary.
You shouldn't store future dates as UTC, bit of a recipe for disaster.
Timezones change, and far more frequently than you'd think.
So storing in UTC is only a good idea for dates in the past.
You'd be in for a world of hurt when the EU or UK finally decide to get rid of moving their clocks forwards/back. They've both been debating it for years. Or Turkey decides to move the start of summer time again with a couple of weeks notice.
The most interesting case of a time format for storage was the time they were shot for uploaded photos. The best answer was effectively save it as a local string. Together with the location it fully 'captures the moment'. This was apparent when showing new year's celebration photos with a date-time in the viewers timezone.
I probably should've just skipped trying to make the time analogy as it is more nuanced as you point out. Or maybe I should've just pointed out that storing in UTC doesn't mean you shouldn't store the offset/region/sub-region etc. I assumed when I said conversion for the display that it would be obvious you need those to make it happen, but I guess people could think I meant to use the browser's tz setting for display/actions (yikes).
But to point out an example, Postgres (and most major DB's today) store all timestamptz as UTC internally with the region code they use for offset calculations. At least for postgres the region code and offset are taken from the IANA DB.
Essentially what I have done, many times, on complex systems is the same thing Postgres is doing just under our applications control and not relying on a specific databases implementation of conversions. This made it easier for us to ship data around between systems without having to care whether those systems had good timezone support. We then had libraries in each language that would handle all the proper conversions/lookups. Meaning (and using your example) if we needed to update future dates for Turkey, we could issue a query to do so and be done. This eliminates having to wait for Postgres to get updates from IANA, update, test and release and then we do the same. Not to mention you need to multiply that by X number of other systems which have their own TZ conversions at that point if you aren't doing it. And then what happens if one gets it wrong or is late to update.
There are many times this just isn't necessary of course, small systems, systems that are only regional, systems where time isn't a critical component etc. But for systems where time crosses many regions and is critical, or is a legal record or triggers an action it becomes more and more important.
FWIW too: A number of US states have passed laws to go to DST only, so no more switching in those either. They are just waiting on the federal government to pass the resolution allowing it (apparently states can opt for standard time but not DST without approval). When that happens a number of America/XXX regions will need to be split up in IANA. For example, America/New_York currently covers Florida but that would have to change.
Thanks! There is an FAQ at https://diff.blog/FAQ/. It used to be linked form the left sidebar. But I made a major website redesign a couple of months back, which removed that sidebar. Will add it back soon :)
