3 ms·
This starts out to be the way most companies think, then before you know it you are big enough to start opening datacenters in other countries, then you have to
by res0nat0r 12y ago
This starts out to be the way most companies think, then before you know it you are big enough to start opening datacenters in other countries, then you have to deal with timestamp conversion.
- maddev 12y agoWhy would you ever need to convert a timestamp? You typically parse a timestamp like "1999-03-29 20:02:04 CEST" and return a number of seconds since a given point in time (e.g. UNIX epoch if it must be). The returned time is obviously +0000 == UTC. If it's not your language/os/software sucks and its no wonder your hair is on fire.
- forgottenpass 12y agoYou typically parse a timestamp like "1999-03-29 20:02:04 CEST" and return a number of seconds since a given point in time (e.g. UNIX epoch if it must be). There's your conversion. I'm not saying it's not easy, I'm saying you're just pulling you out of a hole that your tools were configured to dig.
- supine 12y agoAn example of some of the pitfalls involved: http://search.cpan.org/~drolsky/DateTime-1.10/lib/DateTime.pm#How_DateTime_Math_Works http://search.cpan.org/~drolsky/DateTime-1.10/lib/DateTime.p...
- deleted 12y ago[deleted]
- korzun 12y agoBecause it's always easier said than done. Multiple applications in different languages that are running on different environments and managed by different teams posses a real challenge.
- maddev 12y agoIt's not like am speculating. I implemented these things. The hardest part is agreeing on TZ symbols (e.g. Indian Standard Time vs Ihoa Standard Time). E.g. its not very hard to get right.