Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bug story: Sorting by timestamp

adam-p.ca

Post reply on HN
Print view View original

11–20 of 49 posts

Re: Bug story: Sorting by timestamp

#11

Post by gwbas1c »

dotancohen wrote: post #3

Another common reason that time goes backwards is DST. The amount of DST-related bugs that I've fixed over the years amazes me, because every single developer has moved clocks back and forth twice a year for their entire lives, bar a few years in the beginning. And even this fine article mentions the time-has-gone-back possibility yet ignores DST.

> The amount of DST-related bugs that I've fixed over the years amazes me

> yet ignores DST

Uhm, you do know that you're supposed to use a neutral timezone (Such as UTC) internally in your code / schema, and convert to local time in the UI?

The bugs that I've hit generally have to do with using local time accidentally when UTC is expected.

> because every single developer has moved clocks back and forth twice a year for their entire lives

WTF? Every single developer knows that their database schema should be in UTC and thus immune to DST issues.

Re: Bug story: Sorting by timestamp

#12

Post by _kst_ »

dotancohen wrote: post #3

Another common reason that time goes backwards is DST. The amount of DST-related bugs that I've fixed over the years amazes me, because every single developer has moved clocks back and forth twice a year for their entire lives, bar a few years in the beginning. And even this fine article mentions the time-has-gone-back possibility yet ignores DST.

That should only matter if times are stored and sorted as local time. Storing time as UTC (e.g. seconds since 1970) and computing local time from that and the current time zone should avoid DST-related bugs.

Re: Bug story: Sorting by timestamp

#13

Post by Terr_ »

WirelessGigabit wrote: post #5

Sidenote on showing (or not showing) timestamps. Consider a page with 10 rows, and in each row you show the relative date. 2 issues with that: 1) If I see a whole page and I see 1 week ago the range is 7 days. If I see 1 year ago the range is 365 days. That is too much for most of the things. 2) If I am on a page without visual indication of sort order and I'm on a page that shows 10 entries with '1 year ago' I have…

To be pedantic, that's not a problem of relatives times as much as the data being lossy vague approximations.

Still, "1 year, 7 months, 2 days, 5 hours, 3 minutes ago" isn't always ideal either, not even when it's done in a lexically sortable way.

Ultimately it boils down to a choice which doesn't match problem the user has, and in different circumstances someone might want relative or absolute.

Re: Bug story: Sorting by timestamp

#14

Post by gwbas1c »

loloquwowndueo wrote: post #9
dotancohen wrote: post #3

Another common reason that time goes backwards is DST. The amount of DST-related bugs that I've fixed over the years amazes me, because every single developer has moved clocks back and forth twice a year for their entire lives, bar a few years in the beginning. And even this fine article mentions the time-has-gone-back possibility yet ignores DST.

Every single US developer maybe. In Mexico DST started in 1994 so developers who started before that (hello!) did need some adjustment and operating system support was not a given. There are also countries where DST is not observed or differs from the US yet developers from those countries might be working remotely for a US company, with US developers or needing to accommodate a significant US clientele.

DST is common throughout the world: The days that it starts and stops vary, both by locale, and by year.

The operating system keeps track of every locale's DST dates, all the way as long as DST has been a thing. When governments change the date, via law changes, the change usually gets passed along in an OS update.

Re: Bug story: Sorting by timestamp

#15

Post by [deleted] »

gwbas1c wrote: post #14
loloquwowndueo wrote: post #9

Earlier quoted context omitted.

Every single US developer maybe. In Mexico DST started in 1994 so developers who started before that (hello!) did need some adjustment and operating system support was not a given. There are also countries where DST is not observed or differs from the US yet developers from those countries might be working remotely for a US company, with US developers or needing to accommodate a significant US clientele.

DST is common throughout the world: The days that it starts and stops vary, both by locale, and by year. The operating system keeps track of every locale's DST dates, all the way as long as DST has been a thing. When governments change the date, via law changes, the change usually gets passed along in an OS update.

[deleted]

Re: Bug story: Sorting by timestamp

#16

Post by e28eta »

gwbas1c wrote: post #11
dotancohen wrote: post #3

Another common reason that time goes backwards is DST. The amount of DST-related bugs that I've fixed over the years amazes me, because every single developer has moved clocks back and forth twice a year for their entire lives, bar a few years in the beginning. And even this fine article mentions the time-has-gone-back possibility yet ignores DST.

> The amount of DST-related bugs that I've fixed over the years amazes me > yet ignores DST Uhm, you do know that you're supposed to use a neutral timezone (Such as UTC) internally in your code / schema, and convert to local time in the UI? The bugs that I've hit generally have to do with using local time accidentally when UTC is expected. > because every single developer has moved clocks back and forth twice a year…

It sounds like you’re ignoring the fact that sometimes programs want to do things based on the user’s current time, and there _are_ reasons for developers to need to be aware of DST and handle edge cases correctly.

I inherited some code that was sending push notifications to users with a daily summary. I don’t remember why it was tripping over DST, since the notifications were at a “reasonable” hour (9am?) and afaik the time change happens during the hours most people are asleep, but the ruby API being used had errors for “there are zero / two times that match the time you asked for”.

I had to scratch my head for a little on why we were seeing both the zero and two errors in September / October, despite being intellectually well aware that the southern hemisphere seasons are the opposite of the northern.

Re: Bug story: Sorting by timestamp

#17

Post by takinola »

e28eta wrote: post #16
gwbas1c wrote: post #11

Earlier quoted context omitted.

> The amount of DST-related bugs that I've fixed over the years amazes me > yet ignores DST Uhm, you do know that you're supposed to use a neutral timezone (Such as UTC) internally in your code / schema, and convert to local time in the UI? The bugs that I've hit generally have to do with using local time accidentally when UTC is expected. > because every single developer has moved clocks back and forth twice a year…

It sounds like you’re ignoring the fact that sometimes programs want to do things based on the user’s current time, and there _are_ reasons for developers to need to be aware of DST and handle edge cases correctly. I inherited some code that was sending push notifications to users with a daily summary. I don’t remember why it was tripping over DST, since the notifications were at a “reasonable” hour (9am?) and afaik…

But using UTC solves that problem, no? The time only changes in DST but not in UTC. If the code checks the time against UST, it will never trip up.

Anyways, the only real solution for managing time is to use a library like Luxon so you can stop thinking about it. Time is like cryptographic encryption - Don't roll your own solution if there is a battle tested library available.

Re: Bug story: Sorting by timestamp

#18

Post by o11c »

gwbas1c wrote: post #14
loloquwowndueo wrote: post #9

Earlier quoted context omitted.

Every single US developer maybe. In Mexico DST started in 1994 so developers who started before that (hello!) did need some adjustment and operating system support was not a given. There are also countries where DST is not observed or differs from the US yet developers from those countries might be working remotely for a US company, with US developers or needing to accommodate a significant US clientele.

DST is common throughout the world: The days that it starts and stops vary, both by locale, and by year. The operating system keeps track of every locale's DST dates, all the way as long as DST has been a thing. When governments change the date, via law changes, the change usually gets passed along in an OS update.

Note that Windows has major bugs here - from memory, it only keeps track of the 2 most recent DST rules, so historical timestamps will be wrong after the rules change twice.

Re: Bug story: Sorting by timestamp

#19

Post by recursive »

takinola wrote: post #17
e28eta wrote: post #16

Earlier quoted context omitted.

It sounds like you’re ignoring the fact that sometimes programs want to do things based on the user’s current time, and there _are_ reasons for developers to need to be aware of DST and handle edge cases correctly. I inherited some code that was sending push notifications to users with a daily summary. I don’t remember why it was tripping over DST, since the notifications were at a “reasonable” hour (9am?) and afaik…

But using UTC solves that problem, no? The time only changes in DST but not in UTC. If the code checks the time against UST, it will never trip up. Anyways, the only real solution for managing time is to use a library like Luxon so you can stop thinking about it. Time is like cryptographic encryption - Don't roll your own solution if there is a battle tested library available.

It does not. I've got a specification that all inputs and outputs are in local time. Sometimes the timezone isn't known yet. Or at all.

Re: Bug story: Sorting by timestamp

#20

Post by out_of_protocol »

recursive wrote: post #19
takinola wrote: post #17

Earlier quoted context omitted.

But using UTC solves that problem, no? The time only changes in DST but not in UTC. If the code checks the time against UST, it will never trip up. Anyways, the only real solution for managing time is to use a library like Luxon so you can stop thinking about it. Time is like cryptographic encryption - Don't roll your own solution if there is a battle tested library available.

It does not. I've got a specification that all inputs and outputs are in local time. Sometimes the timezone isn't known yet. Or at all.

Well, when it's not time, just some numbers. The most you can do is to store as is, hoping to figure out what that means later.

Also, even if all inputs and outputs are in local time, it still makes sense to process everything in UTC. There are a lot of weird corner cases making math on datetime really complicated

Post reply on HN