41–50 of 117 posts
A unix timestamp does not have different timezones. It is a counter. No matter where u are in the world a timestamp call should give you the same numeric value at the same instant. It is not time zone adjusted. Store that number, unadjusted as the source of truth. You can get to any local time after that.
Earlier quoted context omitted.
UTC for past events doesn't always work either. For example, historical employee punch-in times. UTC timestamps should only ever be used for points in time in the most literal sense, and nothing else.
If past timestamps (UTC or otherwise) are unreliable, then there is some kind of math-bug going on.
The bottom line is, if wall time is important, past or present, wall time needs to be stored.
The only thing that can be guaranteed about a UTC timestamp is it's a UTC timestamp.
Future events: store the local (at the event) date and time and timezone. You’ll keep the right context even if lawmakers decide to switch things up. You want to see your doctor at 8:30 AM on Monday September 14, 2026 whether it’s daylight saving time, or standard time or “they” decide on a fractional hour offset between the time you set the appointment and the time you attend the appointment. Past events: UTC timest…
You can just use a TIMESTAMP with no TZ data. It's functionally the same as using the string but simpler because you avoid all the string handling headaches and gain the benefit of avoiding to avoid double booking and date/time functions to answer questions like "how many appointments do I have in April?".
This problem is not new and is a relatively minor exposure to the sort of issues that TZ conversion constantly needs to deal with. Different parts of the world have different dates that they adopt (or don't adopt) DST and some nations have changed this date in the past. Use a library, do not roll it yourself, do not try to outsmart tzdata... if you think you could then please volunteer for this project and either bec…
Earlier quoted context omitted.
If past timestamps (UTC or otherwise) are unreliable, then there is some kind of math-bug going on.
Not always a math bug. Sometimes a human bug. Tzdata can have errors (it's crowdsourced after all) that cause past UTC stamps to be incorrect because that incorrect tzdata was used at conversion time. And since most people aren't storing the tzdata version they're using with the stamp, it would be very difficult to make corrections without also corrupting other stamps. The bottom line is, if wall time is important, p…
Dumb change on the part of British Columbia. Source: me, BC resident.
Why?
The change was made (partly) based on a bullshit poll of residents, that asked basically "Hey which would you rather do, use year-round Daylight Savings Time or keep switching every six months?" - notably not including the option a lot of people wanted (and which is well-supported by a lot of research as the best option), which was "use year-round Standard Time".
And then in a bunch of press conferences and answers to the public, they would say "oh, this is what people chose" from the poll.
Earlier quoted context omitted.
If past timestamps (UTC or otherwise) are unreliable, then there is some kind of math-bug going on.
Not always a math bug. Sometimes a human bug. Tzdata can have errors (it's crowdsourced after all) that cause past UTC stamps to be incorrect because that incorrect tzdata was used at conversion time. And since most people aren't storing the tzdata version they're using with the stamp, it would be very difficult to make corrections without also corrupting other stamps. The bottom line is, if wall time is important, p…
Most of my career I’ve seen problems where it’s out of date, never where it’s up to date and wrong.
Earlier quoted context omitted.
UTC for past events doesn't always work either. For example, historical employee punch-in times. UTC timestamps should only ever be used for points in time in the most literal sense, and nothing else.
Why not? It sounds like it would be correct even if the employee has a shift that includes a offset change. Future timestamps should be local because local timezone changes literally change the instant the event it will happen (relative to UTC). For past things, this can’t happen
Earlier quoted context omitted.
Why?
No the OP, but I'm also in BC and dislike this change. The change was made (partly) based on a bullshit poll of residents, that asked basically "Hey which would you rather do, use year-round Daylight Savings Time or keep switching every six months?" - notably not including the option a lot of people wanted (and which is well-supported by a lot of research as the best option), which was "use year-round Standard Time".…