Just make sure your system can handle 23 hour and 25 hour days and hope no one is on at "midnight"...

I found a way around the problem - let JS figure it out.

Basically I needed the current year as of PST (not the user's browser).

i thought you just use UTC and it is sorted?

What happens is, both USA and UK change for daylight savings time - but USA altered the dates, so there are a few weeks overlap at each change where the usual difference is +/- 1.

So in the winter the difference is the same as normal, but for two weeks in November (or whatever) it is 1 hour less.

Also, you compare PDT (daylight time, the summer version) to GMT (standard time, the winter version, also equal to UTC) - the normal match up is PDT to BST (British Summer Time).

A horrible mess I have to deal with for a couple of weeks twice a year, I just do it manually.

You still have to do the math when it's converted back to local time, depending on use cases of course. The problem I remember running into was with drill down graphs that would get a little confused if a day only had 23 hours or had 25 hours.

I had the advantage in that I only care about year. So I only have to be right around 12/31 - 1/1. But still - what is LA in Dec. - UTC - 8?

I only store data in UTC. User asks for time range in their local time format, I convert to UTC and get data, then any dates in the data get converted to local time format. It takes a bit to get all the conversions right and not miss any, but once you're done it's so much easier to reason about.

I also don't do time ranges by length, like if I want to graph "one day" I don't say "start at this date and add 24h" I just say "get data and graph it from datetimeX to datetimeY" where those will be like 2019-02-05T00:00 to 2019-02-06T00:00. The graphing infrastructure doesn't know what length the interval it's graphing contains so it doesn't care if that day has 23 24 or 25 hours.

You can even pretty easily mix and match time zones since every time you're handed gets instantly converted to UTC.

In my case the user needs to see the year in PST, not their local time zone, since that's when the tax summary data rolls over in the back end (we show them current year and previous year summaries).

So at 2am 1/1 2020, the user on the East Coast will still see 2019 for one more hour.

OK? Store the data in UTC anyway and treat pacific as their local time zone. All the stuff you're worried about just disappears

Yeah. +1 to always use and store UTC internally and then apply timezone specific logic on top of that for the cases you need it.

Yes. In December, LA (PST) is UTC -8.

Proxy on your web server >>>>> dealing with cors

Cors gave us all kinds of trouble

Cors in spring is absolutely dreadful. They overly enforce stuff, have weird defaults (don't include put or delete in the default allowed requests) and don't you dare have a trailing slash on your allowed origins!

Anyone with a lot of experience with Datadog? How developer friendly is it, in terms of being able to quickly add some logging and getting metrics up and running? I was thinking of using it more for product insight instead of the more common use case of app health/performance monitoring but I don't know if the tooling is right and/or if it's easy or cumbersome to set it up end to end to get real-time insight. Is there a lot to gain (or to lose) by using Datadog vs just dumping structured logs directly over to Hive and use standard BI tools?

Caveat, I know that your can set up alerts and monitors using JSON which makes me think they may have some robust APIs that I haven't seen. The below is my experience using just the UI just for stats collection.

Datadog is great if you just want basic aggregate numbers or trends eg you can collect the data you need by just incrementing the counter or reporting a stat for some key.

Tags don't seem to be of a ton of use beyond simple segmenting by prod/stag/test or whatever though.

Setup was very easy for a Ruby application. I expect dogstats to be just as easy to set up with any other language that they provide a library for.

We use it extensively for server monitoring and then lightly for apps. Things like tracking percentage of requests with 4xx or 5xx response status codes. Where we report stats more directly I often find that we will also need structured logs.

Tldr structured logs are better for what I think your use case is. Unless you want pretty dashboards or automated alerts.

Re: dealing with timezones in code:

Lol 61 seconds in a minute. Brutal.

moment-timezone for the whole world is 100MB or something. And that's just current. Trying to do historical is impossible.

Indiana used to have towns that were 1/2 hour ahead or behind and I think even 1/4 hour in some cases - until they finally standardized it.

A fun test I always use to see if someone's zip-code->time zone converter is up to snuff is put in a zip code from the Navajo nation (4 corners area) in AZ. AZ doesn't do daylight savings time. But the Navajo nation does.

There are still some time zones that are 30 minutes or 15 minutes off the hour boundaries. I think Nepal is still 15 minutes off?

I worked some place once that did a lot of stuff themselves that they should have used libraries for. I wrote a time zone library for them, and I learned a lot more about time zones than I wanted to know. That experience, plus fixing a major security hole in their DNS resolver, made me realize that some things are complicated enough that you should let someone make it their whole job, and then you should piggy back off that work.

I don't see how a timezone file for just current time zones could be 100MB...

Yeah I'm way off. https://momentjs.com/timezone/

I think they trimmed it down some because I do remember it being pretty big for the whole world. We only needed the US so we generated one with just that info. to get the size down.

Well but then again - in the US you still need way to map zip code to time zone and this file doesn't have that. And in other countries with multiple time zones you need some way to find out what time zone a place is in. Maybe that's where the files get huge.

Well-designed platform and microservices - lacking proper oversight and quality control at the application level.

+1 good video and enjoy the channel overall.

Also for those that don't watch the conclusion os basically what Rusty said about using (and thanking) people that make it thier job.

Time zones, cross-browser weirdness, test-runners, crypto, soap client, parsers, websocket client/server, http server - what else do you never want to write your own?

Does crypto cover login credentials and credit card info storage?

Yep. Among other things like securing data during transport