awful programming: feature flags and suffering

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > YOSPOS > awful programming: feature flags and suffering

«‹›1115 »

FlapYoJacks: Feb 12, 2009

Always a great video to watch about time and timezones:

https://www.youtube.com/watch?v=-5wpm-gesOY&hd=1

# ? Nov 8, 2018 16:09

Adbot: ADBOT LOVES YOU

# ? Apr 23, 2024 18:33

gonadic io: Feb 16, 2011; >>=

ratbert90 posted:

Always a great video to watch about time and timezones:

https://www.youtube.com/watch?v=-5wpm-gesOY&hd=1

i don't know who said it, but: i used to be in favour of space colonisation until i realised what it would mean for datetime handling code

mars days are 25 hours long for example

# ? Nov 8, 2018 16:19

Shaggar: Apr 26, 2006

mars can use eastern time same as everywhere else

# ? Nov 8, 2018 16:20

CRIP EATIN BREAD: Jun 24, 2002; Hey stop worrying bout my acting bitch, and worry about your WACK ass music. In the mean time... Eat a hot bowl of Dicks! Ice T; Soiled Meat

gonadic io posted:

i don't know who said it, but: i used to be in favour of space colonisation until i realised what it would mean for datetime handling code

mars days are 25 hours long for example

or that the perceived passing of time changes depending on your speed

# ? Nov 8, 2018 16:21

AggressivelyStupid: Jan 9, 2012

Shaggar posted:

mars can use eastern time same as everywhere else

# ? Nov 8, 2018 16:22

gonadic io: Feb 16, 2011; >>=

CRIP EATIN BREAD posted:

or that the perceived passing of time changes depending on your speed

well for satellites which suffer from this they just have to keep re-syncing with earth time nbd. will suck yeah when people that actually care about how much time has passed start traveling at those speeds and higher though

# ? Nov 8, 2018 16:24

CRIP EATIN BREAD: Jun 24, 2002; Hey stop worrying bout my acting bitch, and worry about your WACK ass music. In the mean time... Eat a hot bowl of Dicks! Ice T; Soiled Meat

gonadic io posted:

well for satellites which suffer from this they just have to keep re-syncing with earth time nbd. will suck yeah when people that actually care about how much time has passed start traveling at those speeds and higher though

true that's fine for earth-centric satellites but what do you about things that have never even been to earth?

# ? Nov 8, 2018 16:47

Janitor Prime: Jan 22, 2004; PC LOAD LETTER

What da fuck does that mean; Fun Shoe

CRIP EATIN BREAD posted:

true that's fine for earth-centric satellites but what do you about things that have never even been to earth?

ntp works in space right?

# ? Nov 8, 2018 16:50

cinci zoo sniper: Mar 15, 2013

Shaggar posted:

mars can use eastern time same as everywhere else

# ? Nov 8, 2018 16:52

CRIP EATIN BREAD: Jun 24, 2002; Hey stop worrying bout my acting bitch, and worry about your WACK ass music. In the mean time... Eat a hot bowl of Dicks! Ice T; Soiled Meat

Janitor Prime posted:

ntp works in space right?

the round trip delay will be shifted depending on the relative velocity of the client and server. for two points on earth its fine. for satellites it's fine. for interstellar travel? not too much.

# ? Nov 8, 2018 16:55

Shaggar: Apr 26, 2006

CRIP EATIN BREAD posted:

true that's fine for earth-centric satellites but what do you about things that have never even been to earth?

if their so alien we cant communicate with them then we don't need to worry about their concept of time but if we can communicate with them they can use eastern time.

# ? Nov 8, 2018 16:56

Nomnom Cookie: Aug 30, 2009

CRIP EATIN BREAD posted:

the round trip delay will be shifted depending on the relative velocity of the client and server. for two points on earth its fine. for satellites it's fine. for interstellar travel? not too much.

that sounds like an algorithm problem that the boffins will solve once and everyone uses the solution and it works fine. what will gently caress everything is the per-ship DST rules

Shaggar posted:

if their so alien we cant communicate with them then we don't need to worry about their concept of time but if we can communicate with them they can use eastern time.

shaggar

# ? Nov 8, 2018 17:40

prisoner of waffles: May 8, 2007; Ah! well a-day! what evil looks
Had I from old and young!
Instead of the cross, the fishmech
About my neck was hung.

yeah, so there's UT (atomic clock, uncorrected), UTC (UT with leap seconds, the basis for civil time now), UT1 (sidereal time, based on Earth rotation i.e. what astronomers use) for major terrestrial time systems

then there's BDT, barycentric dynamic time, which is supposed to be good for some sorry of general purposes within the solar system

# ? Nov 8, 2018 17:52

Finster Dexter: Oct 20, 2014; Beyond is Finster's mad vision of Earth transformed.

I was gonna post a pun about this but it's no longer timely :v:

# ? Nov 8, 2018 18:07

dick traceroute: Feb 24, 2010; Open the pod bay doors, Hal.; Grimey Drawer

Finster Dexter posted:

I was gonna post a pun about this but it's no longer timely

Post it with the offset then

# ? Nov 8, 2018 20:08

ComradeCosmobot: Dec 4, 2004; USPOL July

gonadic io posted:

i don't know who said it, but: i used to be in favour of space colonisation until i realised what it would mean for datetime handling code

mars days are 25 hours long for example

just look at all this junk and tell me interplanetary time is simple

# ? Nov 8, 2018 20:11

VikingofRock: Aug 24, 2008

gonadic io posted:

i don't know who said it, but: i used to be in favour of space colonisation until i realised what it would mean for datetime handling code

mars days are 25 hours long for example

Just do the Red Mars solution and have 37 minutes of each day which are not part of any hour and in which clocks don't move.

Also build a space elevator

# ? Nov 8, 2018 22:15

Powerful Two-Hander: Mar 10, 2004; Mods please change my name to "Tooter Skeleton" TIA.

VikingofRock posted:

Just do the Red Mars solution and have 37 minutes of each day which are not part of any hour and in which clocks don't move.

Also build a space elevator

drat was about to post this.

once you get the space elevator just stop thought because it only gets worse from there

# ? Nov 8, 2018 23:42

VikingofRock: Aug 24, 2008

Powerful Two-Hander posted:

drat was about to post this.

once you get the space elevator just stop thought because it only gets worse from there

Not a fan the geriatric fertility cult in book 2?

VikingofRock fucked around with this message at 00:53 on Nov 9, 2018

# ? Nov 9, 2018 00:50

Powerful Two-Hander: Mar 10, 2004; Mods please change my name to "Tooter Skeleton" TIA.

VikingofRock posted:

Not a fan the geriatric fertility cult in book 2?

i actually went back and read all three the other year because when I was about 12 I only got half way through green Mars before I got bored (and probably weirded out by the geriatric sex cult tbh) and well, I guess all I missed was another 1000 pages of sex cults and talking about clouds

so many pages about clouds jfc

# ? Nov 9, 2018 12:12

MononcQc: May 29, 2007

Janitor Prime posted:

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!

I''m super late but,

Store everything in UTC except when you are referring to a local event, specifically a future one. Since the time-to-UTC conversion takes place at creation time because that's what you store, the problem you'll get with it is that it will generally ignore changes in DST or DST policies. The best way to explain that problem is to think of google calendars. It asks you to store the timezone of the event, and defaults to your current one.

The problem with that is that there are two possible desirable behaviors:

If it's around Feb 16, and you're having a meetup with people within New York City, you might want to set it at 7pm in 1 month, and send invites. Unfortunately, at the time of setting the meeting, the timezone is -05:00; March 16 falls after the switch to DST, which means the local time will by then be -04:00. If you aren't careful, the meeting will now be re-scheduled one day ahead of time to be at 8pm
If you're instead having an important remote business meeting or call with people across various offices, which include people in Europe and NYC, you will have wanted to store the time in UTC, because the DST switch between most of the US (Arizona excluded) and Europe is offset by two weeks (until EU decides what it does with DST), and so using a localized time shifts the meeting time more than UTC in terms of relative/absolute terms.

So just "display in user locale and store UTC" is 90% good advice, but when it comes to scheduling future and local events, you want to know the locale and operate based on that if you want to properly represent things such as meetings, concerts, opening hours, flight schedules, and so on. Location turns out to be critical because everyone involved (except for the computer system) operates in that frame and context. UTC becomes a fallback when you can't necessarily know the local time or can't guarantee what it will be at the time of communications.

In most cases you may want to always store a UTC timestamp, but make a strict distinction between "desired time" and "calculated time". The desired time represents what the user expected (thing happening at X locally) and the calculated time the one you would use for broader system automation (alerting and events). When laws or DST or context changes, you can re-derive the calculated time from the desired time and self-repair/update the system.

# ? Nov 9, 2018 15:38

MononcQc: May 29, 2007

VikingofRock posted:

Just do the Red Mars solution and have 37 minutes of each day which are not part of any hour and in which clocks don't move.

Also build a space elevator

intercalary periods like that are also how some arithmetic calendars deal with leap days, particularly in calendars with strict monthly cycles (e.g. the coptic has 12x30 day months), In such cases, there might just be days added at the end of arbitrary cycle. The coptic calendar has 5 days hanging free that are not part of any months, 6 on leap years. The Bah�'� calendar works the same, with 9 months of 19 days each (361 days) plus an extra period of days at the end, where they align the rest (in their case they use Gregorian rules for leap day calculations, whereas Coptic is on the Julian rule iirc).

lunisolar calendars where the moon cycle dictates month length, but the solar cycle defines the year length tend to instead sync everything up by adding full blown months. The Hebrew calendar does things in a special manner where they calculate intersections between the lunar and solar cycle and when they cross over, they add one whole month (Adar I) that goes in front of regular Adar and re-syncs the clocks. The Chinese calendar also did something similar to that. The Hindu calendar will just repeat some months when that happens.

Basically, the mars rover's day works like the coptic and bahai calendars, and the DST on earth works like lunisolar calendars by replaying or adding time :toot:

# ? Nov 9, 2018 15:48

prisoner of waffles: May 8, 2007; Ah! well a-day! what evil looks
Had I from old and young!
Instead of the cross, the fishmech
About my neck was hung.

have I forgotten green mars? I thought it was a geriatric baby-manufacturing cult- like they could have all been freakydeaky but that was irrelevant, ectogenic babies were the big deal

# ? Nov 9, 2018 15:50

Nomnom Cookie: Aug 30, 2009

MononcQc posted:

I''m super late but,

Store everything in UTC except when you are referring to a local event, specifically a future one. Since the time-to-UTC conversion takes place at creation time because that's what you store, the problem you'll get with it is that it will generally ignore changes in DST or DST policies. The best way to explain that problem is to think of google calendars. It asks you to store the timezone of the event, and defaults to your current one.

The problem with that is that there are two possible desirable behaviors:

If it's around Feb 16, and you're having a meetup with people within New York City, you might want to set it at 7pm in 1 month, and send invites. Unfortunately, at the time of setting the meeting, the timezone is -05:00; March 16 falls after the switch to DST, which means the local time will by then be -04:00. If you aren't careful, the meeting will now be re-scheduled one day ahead of time to be at 8pm

If you're instead having an important remote business meeting or call with people across various offices, which include people in Europe and NYC, you will have wanted to store the time in UTC, because the DST switch between most of the US (Arizona excluded) and Europe is offset by two weeks (until EU decides what it does with DST), and so using a localized time shifts the meeting time more than UTC in terms of relative/absolute terms.

So just "display in user locale and store UTC" is 90% good advice, but when it comes to scheduling future and local events, you want to know the locale and operate based on that if you want to properly represent things such as meetings, concerts, opening hours, flight schedules, and so on. Location turns out to be critical because everyone involved (except for the computer system) operates in that frame and context. UTC becomes a fallback when you can't necessarily know the local time or can't guarantee what it will be at the time of communications.

In most cases you may want to always store a UTC timestamp, but make a strict distinction between "desired time" and "calculated time". The desired time represents what the user expected (thing happening at X locally) and the calculated time the one you would use for broader system automation (alerting and events). When laws or DST or context changes, you can re-derive the calculated time from the desired time and self-repair/update the system.

in summary, groupware is a gently caress and working on it is barely preferable to homelessness

# ? Nov 9, 2018 16:29

Nomnom Cookie: Aug 30, 2009

software for managing interactions between people is that peculiar combination of really hard and really boring

# ? Nov 9, 2018 16:30

Finster Dexter: Oct 20, 2014; Beyond is Finster's mad vision of Earth transformed.

lmao imagine being python 3.7 and being many times slower than garbo p-lang php 7.

https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/php.html

# ? Nov 9, 2018 19:44

bob dobbs is dead: Oct 8, 2017; I love peeps; Nap Ghost

Finster Dexter posted:

lmao imagine being python 3.7 and being many times slower than garbo p-lang php 7.

https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/php.html

comparing a bunch of numerics poo poo and not using numpy, lol

# ? Nov 9, 2018 19:50

Finster Dexter: Oct 20, 2014; Beyond is Finster's mad vision of Earth transformed.

bob dobbs is dead posted:

comparing a bunch of numerics poo poo and not using numpy, lol

that's on the dopes submitting lovely python programs that don't use it, then.

# ? Nov 9, 2018 20:00

bob dobbs is dead: Oct 8, 2017; I love peeps; Nap Ghost

Finster Dexter posted:

that's on the dopes submitting lovely python programs that don't use it, then.

exactly. they use obscure numerics libs for arbitrary digit poo poo but don't use numpy, which will routinely produce 40x, 100x speedups over even pretty smart native python code

# ? Nov 9, 2018 20:05

Finster Dexter: Oct 20, 2014; Beyond is Finster's mad vision of Earth transformed.

I'm gonna show these rust v. go numbers to the cto and see if I can convince him to start using rust instead of golang.

https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/rust-go.html

# ? Nov 9, 2018 20:13

CRIP EATIN BREAD: Jun 24, 2002; Hey stop worrying bout my acting bitch, and worry about your WACK ass music. In the mean time... Eat a hot bowl of Dicks! Ice T; Soiled Meat

yeah it's almost as if using numpy, a library written in C to do any real work instead of python would be a lot faster

wild stuff

(python sucks)

# ? Nov 9, 2018 21:27

redleader: Aug 18, 2005; Engage according to operational parameters

CRIP EATIN BREAD posted:

yeah it's almost as if using numpy, a library written in C to do any real work instead of python would be a lot faster

wild stuff

(python sucks)

all plangs suck

# ? Nov 9, 2018 21:44

bob dobbs is dead: Oct 8, 2017; I love peeps; Nap Ghost

redleader posted:

all plangs suck

but my point is python sucks by far the least

# ? Nov 9, 2018 21:57

gonadic io: Feb 16, 2011; >>=

bob dobbs is dead posted:

but my point is python sucks by far the least

agreed, but julia kinda looks interesting (if it counts as a plang, it's weakly and optionally typed)

# ? Nov 9, 2018 21:58

bob dobbs is dead: Oct 8, 2017; I love peeps; Nap Ghost

gonadic io posted:

agreed, but julia kinda looks interesting (if it counts as a plang, it's weakly and optionally typed)

julia has lisp disease
(all the libs suck balls)

# ? Nov 9, 2018 22:11

MrMoo: Sep 14, 2000

bob dobbs is dead posted:

julia has lisp disease
(all the libs suck balls)

Julia can allegedly use any C API without shims, which is pretty handy if you had useful libraries to use.

# ? Nov 9, 2018 23:01

TheFluff: Dec 13, 2006; FRIENDS, LISTEN TO ME
I AM A SEAGULL
OF WEALTH AND TASTE

re: julia, this is from 2014 but it's not encouraging

# ? Nov 10, 2018 00:02

The MUMPSorceress: Jan 6, 2012; ^SHTPSTS; Gary’s Answer

c TP s: debugging on Hadoop remains torture

# ? Nov 10, 2018 00:14

bob dobbs is dead: Oct 8, 2017; I love peeps; Nap Ghost

jit bull transpile posted:

c TP s: debugging on Hadoop remains torture

why are you fuckin touching hadoop in tyool 2018

# ? Nov 10, 2018 00:15

Adbot: ADBOT LOVES YOU

# ? Apr 23, 2024 18:33

Nomnom Cookie: Aug 30, 2009

Finster Dexter posted:

I'm gonna show these rust v. go numbers to the cto and see if I can convince him to start using rust instead of golang.

https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/rust-go.html

do you really think it's a good idea to replace go with a language that has worse usability than c++

# ? Nov 10, 2018 00:16

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > YOSPOS > awful programming: feature flags and suffering

«‹›1115 »