You might as well timestamp it • Hacker News Board

Re: You might as well timestamp it

#71

Post by globular-toast » Sat, Apr 24, 2021, 9:44 AM UTC

progre wrote: post #65

ximm wrote: post #43

One important downside: Data protection. This approach of "store it now in case you might need it later" is in direct violation of the principle of data minimisation in GDPR.

GDPR only applies to personal data though? Like you can't store gender info "in case it's usefull later". I really don't see how a timestamp can be used in that way.

Well, since gender is mutable now, I suppose you can't store the date the gender changed "just in case". But yeah, unless you're dealing with people, this doesn't apply.

Re: You might as well timestamp it

#72

Post by imperistan » Sat, Apr 24, 2021, 9:46 AM UTC

ximm wrote: post #43

One important downside: Data protection. This approach of "store it now in case you might need it later" is in direct violation of the principle of data minimisation in GDPR.

I think thats only the case when it the data can be used to (help) identify a specific person

Re: You might as well timestamp it

#73

Post by globular-toast » Sat, Apr 24, 2021, 9:47 AM UTC

lazyasciiart wrote: post #22

Am I missing something, or does this assume I never care about the timestamp for turning a value off?

Yeah, I don't get that either. This only seems to work in very specific cases, like where the boolean starts off false, becomes true and can never be false again. So like "user viewed homepage". That seems like a tiny subset of what Booleans are used for but it's presented as being the one, obvious use case.

Re: You might as well timestamp it

#74

Post by kijin » Sat, Apr 24, 2021, 9:47 AM UTC

BiteCode_dev wrote: post #54

davidverhasselt wrote: post #23

There is a downside which I've experienced: if you want a triple-state boolean (null, false, true) then having a boolean column allows for that while a timestamp-as-boolean column does not (you lose the "null" value because that equals `false` in timestamp-as-boolean). Having a distinction between `null` and `false` can be handy for values that are optional or have a dynamic default. If it's `null` you know it is not…

If the timestamp is a creation date after your system went on, which it is here, you can always store 0 for false.

-1 can be useful, too, especially if you've already assigned a certain meaning to 0.

Javascript developers are used to certain functions returning -1 if there's no match, so -1 shouldn't feel strange as long as it's well documented.

Re: You might as well timestamp it

#75

Post by andix » Sat, Apr 24, 2021, 9:49 AM UTC

I don’t like NULLs. Nullables always get back you in ways you would never expect.

That’s why I won’t use a tip like that.

Re: You might as well timestamp it

#76

Post by andix » Sat, Apr 24, 2021, 9:51 AM UTC

davidverhasselt wrote: post #23

There is a downside which I've experienced: if you want a triple-state boolean (null, false, true) then having a boolean column allows for that while a timestamp-as-boolean column does not (you lose the "null" value because that equals `false` in timestamp-as-boolean). Having a distinction between `null` and `false` can be handy for values that are optional or have a dynamic default. If it's `null` you know it is not…

Tri-state booleans are also very ugly. What happens if you suddenly need a 4th state?

Use enums (or any equivalent) for states that are non-boolean.

Re: You might as well timestamp it

#77

Post by kijin » Sat, Apr 24, 2021, 9:52 AM UTC

nickjj wrote: post #35

Indeed, I do this pretty much all the time too. One common'ish example not mentioned in the article is storing whether or not a user is active. Storing "is_active" as a boolean makes sense but switching that to "deactivated_at" gives you so much more information.

last_active_at also makes sense, especially if you'd like some flexibility in deciding what to do with users who have been inactive for a certain amount of time.

Re: You might as well timestamp it

#78

Post by usr1106 » Sat, Apr 24, 2021, 9:55 AM UTC

When reading this I miss a HN feature "upvote as a falsehood to be aware of".

Re: You might as well timestamp it

#79

Post by MrOxiMoron » Sat, Apr 24, 2021, 9:55 AM UTC

except when it is actually a nullable Boolean and there is a big difference between the 3 states

Re: You might as well timestamp it

#80

Post by kijin » Sat, Apr 24, 2021, 10:00 AM UTC

cmsefton wrote: post #52

bob1029 wrote: post #45

I don't like this. Yes, you can alias the true/false fact to null/non-null datetime value, but this is missing the point of domain modeling. The immediate impact of this decision is probably negligible as long as you did not need to store a nullable boolean fact, as opposed to a non-nullable boolean fact. The broader impact of this decision is that you have endorsed a policy of assuming how things will be used in the…

The other thing I don't like about this is that it's great at tracking the switch to "true" (the timestamp value), but when you want to go back to "false", you have to wipe out the timestamp, and you then have no idea when it was unpublished or unhidden or whatever. Now you need a second column to track that as I see it, and you start getting into weird territory. IMO it's better to keep the Boolean, and just introdu…

If you need to maintain a proper audit trail for every state change, you need a separate table for that.

Any trick you play with a fixed number of scalar columns will only let you access the timestamp of the last change of the same type. This won't be particularly useful when there's an edit war among moderators who unpublish and republish the same thing over and over.