|
CRIP EATIN BREAD posted:welcome to systems engineering im very happy i need to generalise over only dozen-ish implementations of the same product
|
#
?
Nov 7, 2018 19:28
|
|
|
|
| # ? Apr 20, 2024 05:16 |
|
|
Gazpacho posted:Everyone get ready for a wild ride because california voters just authorized the state to adopt year round DST, based on the argument that DST switching causes heart attacks strokes and incontinence Nah. Only if Congress first passes a bill authorizing California to do that, and  if you think Congress is going to do anything for the next 2 years min.http://www.sandiegouniontribune.com...-htmlstory.html
|
|
#
?
Nov 7, 2018 19:30
|
|
|
adjusting the clocks is stupid and only causes problems. there's zero reason to do it in the year of our lord 2018. however lol at all the stuff that will be broken because of it.
|
|
#
?
Nov 7, 2018 19:32
|
|
|
Gazpacho posted:Everyone get ready for a wild ride because california voters just authorized the state to adopt year round DST, based on the argument that DST switching causes heart attacks strokes and incontinence lmao ezpz. as a backend dev I just store everything as UTC and make the frontend dopes worry about time zone conversions
|
|
#
?
Nov 7, 2018 19:49
|
|
|
Finster Dexter posted:lmao ezpz. as a backend dev I just store everything as UTC and make the frontend dopes worry about time zone conversions idk if you're joking but this doesn't work with e.g. dst
|
|
#
?
Nov 7, 2018 20:24
|
|
|
CRIP EATIN BREAD posted:i wonder how much overhead is incurred by javascript to do all the "magic" that makes it a poo poo language for brain dead morons to easily write trash Honestly I think it still requires webdevs some significant effort to generate such wonderful output.
|
|
#
?
Nov 7, 2018 20:27
|
|
|
pointsofdata posted:idk if you're joking but this doesn't work with e.g. dst As long as the front end is always sending you data in UTC or with time zone information attached you're fine, yeah?
|
|
#
?
Nov 7, 2018 20:54
|
|
|
Chalks posted:As long as the front end is always sending you data in UTC or with time zone information attached you're fine, yeah? yeah, utc doesn't have DST. if you send everything in UTC then you can figure out the correct poo poo (by letting a library handle iut for you)
|
|
#
?
Nov 7, 2018 21:00
|
|
|
I’m sure there are many fine JavaScript date & time libraries for the front end dev hahahaha
|
|
#
?
Nov 7, 2018 21:15
|
|
|
not my problem
|
|
#
?
Nov 7, 2018 21:16
|
|
|
eschaton posted:I’m sure there are many fine JavaScript date & time libraries for the front end dev hahahaha moment.js works fine, displaying dates on a webpage is a pretty solved problem in 2018
|
|
#
?
Nov 7, 2018 21:18
|
|
|
Chalks posted:As long as the front end is always sending you data in UTC or with time zone information attached you're fine, yeah? time zone information? lmfao now you want me to refactor the whole russian codebase to handle incoming time zone information correctly? uhhhhh hmmmmmm 
|
|
#
?
Nov 7, 2018 21:20
|
|
|
Chalks posted:As long as the front end is always sending you data in UTC or with time zone information attached you're fine, yeah? You don't always even need the TZ information, but it's better to have it and not need it. I've found that without it on global services reports like "what do people do at 5pm in their local time" become impossible and then you have to shoehorn it in after the fact and that sucks. See post above ^
|
|
#
?
Nov 7, 2018 22:02
|
|
|
Finster Dexter posted:time zone information? lmfao now you want me to refactor the whole russian codebase to handle incoming time zone information correctly? uhhhhh hmmmmmm hold on ill plug you into this skype chat where me a 2 developers are arguing about the real tz on database
|
|
#
?
Nov 7, 2018 22:04
|
|
|
good thing time doesn't actually exist
|
|
#
?
Nov 7, 2018 22:14
|
|
|
cjs: A lot of shitfuckery this week. I'll sum it up by saying that being tightly coupled to NATS to the degree that services implode because the NATS cluster is gracefully restarted really sucks balls. Although, the CTO offered to work on building a (more) fault tolerant NATS cluster, so that was nice. But now I'm stuck fixing an issue where customer-facing transactional data is irretrievably lost because its service restarted when NATS went down and said data can't be reconstructed from the database, because only the end result of the transactions is ever persisted. Thanks, Russians! Apparently they couldn't figure out why you'd want to ever persist the transactional data anywhere but in memory of the service that processes it. (Supposedly, they have a fix for this issue in their develop branch... which involves persisting the data to NATS "in a file".) 
|
|
#
?
Nov 7, 2018 22:36
|
|
|
cinci zoo sniper posted:hold on ill plug you into this skype chat where me a 2 developers are arguing about the real tz on database It's fine, we're in the UK so we've got 6 months until everyone realises our database server clocks aren't UTC and the panic starts
|
|
#
?
Nov 7, 2018 23:02
|
|
|
cinci zoo sniper posted:hold on ill plug you into this skype chat where me a 2 developers are arguing about the real tz on database oh boy let me tell you about having a database, with long timestamps, that moved from italian local time to amazon local time without any of us making sure that the application normalised it (it didn't) then having to add some logic to the code that checked the db inserted_at time and compared it to the date that we moved to aws
|
|
#
?
Nov 7, 2018 23:05
|
|
|
Chalks posted:It's fine, we're in the UK so we've got 6 months until everyone realises our database server clocks aren't UTC and the panic starts ask me about manually editing config in a text file live on prod each time the clocks changed or we'd start trading an hour late
|
|
#
?
Nov 7, 2018 23:06
|
|
|
gonadic io posted:oh boy let me tell you about having a database, with long timestamps, that moved from italian local time to amazon local time without any of us making sure that the application normalised it (it didn't) oh no. oh no
|
|
#
?
Nov 7, 2018 23:11
|
|
|
Chalks posted:It's fine, we're in the UK so we've got 6 months until everyone realises our database server clocks aren't UTC and the panic starts then eu will phase out winter or summer time
|
|
#
?
Nov 7, 2018 23:12
|
|
|
Ask me about comments on Experts Exchange showing up in the wrong order for an hour every time DST ended and what we did to fix this (nothing).
|
|
#
?
Nov 7, 2018 23:12
|
|
|
ask someone about failing to parse dates of sa posts because the dst info was old and the supposed post time never happened
|
|
#
?
Nov 7, 2018 23:46
|
|
|
Store everything in UTC Only deal with time zones at the edges of your application (input/output) Prefer to transmit date/times in epoch milliseconds Fall back to ISO8601 to transmit date/times as strings, don’t use your own string formatters! Display time in users preferred locale, but do it all the way in the display part of your application!
|
|
#
?
Nov 8, 2018 00:29
|
|
|
Janitor Prime posted:ISO8601 which one?
|
|
#
?
Nov 8, 2018 02:00
|
|
|
and does it count if you drop the Z and offset, which seems really common but I think is nonconforming? aka why I’ve yet to be able to use Foundation.ISO8601DateFormatter
|
|
#
?
Nov 8, 2018 03:02
|
|
|
if there's no offset then it's a local date+time and you're hosed
|
|
#
?
Nov 8, 2018 03:52
|
|
|
I’ve seen multiple apis send timestamps as UTC but without the Z :shrugs: not a difficult thing to deal with, just odd. why bother stopping just short idgi
|
|
#
?
Nov 8, 2018 04:17
|
|
|
i once had to explain to someone why a time without a date didn't make sense to have a timezone and nor did it matter, and it drew out into a long argument
|
|
#
?
Nov 8, 2018 06:25
|
|
|
CRIP EATIN BREAD posted:i once had to explain to someone why a time without a date didn't make sense to have a timezone and nor did it matter, and it drew out into a long argument what’s the tldr on explanation here, time looping around without date being unspecified “yesterday”, “today”, or “tomorrow”?
|
|
#
?
Nov 8, 2018 07:42
|
|
|
for one, if you don't have a date you don't know whether dst was in effect or not
|
|
#
?
Nov 8, 2018 08:35
|
|
|
Sagacity posted:for one, if you don't have a date you don't know whether dst was in effect or not right 
|
|
#
?
Nov 8, 2018 09:00
|
|
|
cinci zoo sniper posted:then eu will phase out winter or summer time yeah, but I'm in the UK CRIP EATIN BREAD posted:i once had to explain to someone why a time without a date didn't make sense to have a timezone and nor did it matter, and it drew out into a long argument kinda depends on how you're sending timezone information, ISO 8601 uses 08:24:46+03:00 so it doesn't actually matter what day it is because you're specifying the exact offset. poo poo gets interesting when you only want to show dates and you're intentionally sending midnight as the start of a day, but their timezone means that's actually the previous day so what are you actually going to show on the screen? spherical planets were a mistake.
|
|
#
?
Nov 8, 2018 09:27
|
|
|
Chalks posted:yeah, but I'm in the UK that’s the joke yes
|
|
#
?
Nov 8, 2018 10:53
|
|
|
Chalks posted:As long as the front end is always sending you data in UTC or with time zone information attached you're fine, yeah? You need to know the timezone if you want to calculate time between two values, 1 hour before a time, bucket events into 5 min bins, calculate sales by month etc correctly. Idk maybe your application is fine and you do no operations on the timezones on the backend but it's really hard to get things right from a business logic perspective without timezone information E: sorry you said with timezone information. In that case you're fine I think
|
|
#
?
Nov 8, 2018 12:30
|
|
|
Chalks posted:kinda depends on how you're sending timezone information, ISO 8601 uses 08:24:46+03:00 so it doesn't actually matter what day it is because you're specifying the exact offset. well time offsets are fixed whereas offsets in timezones are not. dealing with time loving sucks.
|
|
#
?
Nov 8, 2018 13:54
|
|
|
tps: I let the ORM handle time because I don't want that headache
|
|
#
?
Nov 8, 2018 14:15
|
|
|
we solved the time zone issue by just not storing the time zone anywhere and by solved i mean made a nightmare to deal with as we have prisons in multiple time zones
|
|
#
?
Nov 8, 2018 15:25
|
|
|
our logger database uses utc so for 50% of the year you have to remember that the log timestamps are 1 hour out Someone should probably fix that but ehhhhh
|
|
#
?
Nov 8, 2018 15:57
|
|
|
|
| # ? Apr 20, 2024 05:16 |
|
|
I swear I'm the only person that looks at the logs anyway. all the offshore team do is ask me when there's a problem and I just send a screenshot of the logger in the vain hope that somebody will actually engage their brain
|
|
#
?
Nov 8, 2018 15:59
|
|