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

Timezone Bullshit

blog.wesleyac.com

Post reply on HN
Print view View original

161–170 of 334 posts

Re: Timezone Bullshit

#161

Post by twic »

NovemberWhiskey wrote: post #96

I work with a proprietary programming language that internally models a date_time as a UNIX epoch offset. The to_string method of a date_time results in a nice human readable string in the local timezone, but crucially not including the TZ itself. There were also accessors for the HH:MM:SS parts of the date_time . At some point, the problem must've come up "if it's 5pm here in SFO, what time is it in MIA?", or some v…

I wrote an app that does a different but perhaps even more appalling crime.

The app was for displaying time-series data. The data displayed was only generated during business hours. We usually wanted to view a span of a couple of weeks. Displaying it naively, with real time along the x-axis would mean that three-quarters of the display was blank, with only 40 of a week's 168 hours in use.

The obvious thing to do is to elide the blank bits, and just show the spans of time with data (with a little gap in between). But the charting library i was using didn't have the concept of a discontinuous or nonlinear x-axis.

So i wrote a class called TimeCompressor that would collect a set of time-series data, indexed by epoch timestamp, and rewrite the timestamps so that empty spans of time would be compressed. The earliest timestamp in the dataset stays the same, but later ones may be slid earlier in time to compress empty spans. The resulting indices are numbers which look mostly like epoch timestamps, and in some cases actually are epoch timestamps, but really aren't epoch timestamps.

This was all done in JavaScript, so there wasn't a convenient way to wrap the not-really-timestamp indices in a type to mark them as such. So, in this application, when there's a field called somethingTimestamp and it has a large integer that looks like a timestamp in it, sometimes it's a timestamp, and sometimes it isn't!

I am hoping this application will be retired before i ever need to work on it again.

Re: Timezone Bullshit

#162

Post by messe »

soco wrote: post #24
sdm wrote: post #9

> There are actually two timezones that are canonically named "CST", and they're 14 hours apart! Yup. If you say CST do you mean China Standard Time or Central Standard Time? The answer will depend on where you live in the world. There are others that share the same abbreviation as well. But CST is the one that constantly causes trouble in daily life. Just say no.

According to Wikipedia there are more than one overlappings: https://en.wikipedia.org/wiki/List_of_time_zone_abbreviation...

I think BST, CST and IST are the only triple overlaps. I live in one and I'm adjacent to another.

Re: Timezone Bullshit

#163

Post by phaemon »

steerablesafe wrote: post #154
phaemon wrote: post #115

Earlier quoted context omitted.

No it isn't. If you tell your computer that the timezone your machine is set to is called "LOL", then of course that's what it should report. What else would it do? It truncated the name because of the underscores, but you can do `TZ=somerandomthing date` to see it just reports what you say it is.

Various behaviors when requesting time in a non-existent timezone: sane: report an error in some hard to ignore form less sane: ignore the provided timezone, display the time in UTC and properly mark it with "UTC" insane: ignore the provided timezone, display the time in UTC, but then mark it with the prefix of the provided timezone anyway. I don't care how well documented the insane behavior is, it's still insane.

It didn't display the time in UTC, it displayed the time in timezone LOL. It happened to be the same as UTC because no offset was specified. It knew it was timezone LOL because that's what the TZ variable was set to.

If you set your machine to something weird, then expect the utility that reports on those settings to report the weird settings you set.

Re: Timezone Bullshit

#164

Post by twic »

k_sze wrote: post #71

When I use the "full" timezone name like "America/New_York", how does libc resolve the ambiguity during the extra hour of the transition from daylight saving time to standard time?

man mktime on my machine reveals:

> The mktime() function converts a broken-down time structure, expressed as local time, to calendar time representation. The function ignores the values supplied by the caller in the tm_wday and tm_yday fields. The value specified in the tm_isdst field informs mktime() whether or not daylight saving time (DST) is in effect for the time supplied in the tm structure: a positive value means DST is in effect; zero means that DST is not in effect; and a negative value means that mktime() should (use timezone information and system databases to) attempt to determine whether DST is in effect at the specified time.

So, not specified.

POSIX is no clearer about which choice it will make [1]:

> The mktime() function shall convert the broken-down time, expressed as local time, in the structure pointed to by timeptr, into a time since the Epoch value with the same encoding as that of the values returned by time(). The original values of the tm_wday and tm_yday components of the structure shall be ignored, and the original values of the other components shall not be restricted to the ranges described in .

> A positive or 0 value for tm_isdst shall cause mktime() to presume initially that Daylight Savings Time, respectively, is or is not in effect for the specified time. A negative value for tm_isdst shall cause mktime() to attempt to determine whether Daylight Savings Time is in effect for the specified time.

> Local timezone information shall be set as though mktime() called tzset().

> The relationship between the tm structure (defined in the header) and the time in seconds since the Epoch is that the result shall be as specified in the expression given in the definition of seconds since the Epoch (see XBD Seconds Since the Epoch) corrected for timezone and any seasonal time adjustments, where the names other than tm_yday in the structure and in the expression correspond, and the tm_yday value used in the expression is the day of the year from 0 to 365 inclusive, calculated from the other tm structure members specified in (excluding tm_wday).

> Upon successful completion, the values of the tm_wday and tm_yday components of the structure shall be set appropriately, and the other components shall be set to represent the specified time since the Epoch, but with their values forced to the ranges indicated in the entry; the final value of tm_mday shall not be set until tm_mon and tm_year are determined.

... but i think the final paragraph implies that the tm_isdst field in the input time should at least be set to indicate which choice was made!

Java is explicit [2]:

> In most cases, there is only one valid offset for a local date-time. In the case of an overlap, where clocks are set back, there are two valid offsets. This method uses the earlier offset typically corresponding to "summer".

[1] https://pubs.opengroup.org/onlinepubs/9699919799/functions/m...

[2] https://docs.oracle.com/en/java/javase/11/docs/api/java.base...

Re: Timezone Bullshit

#165

Post by happyopossum »

Lvl999Noob wrote: post #53
mabbo wrote: post #47

Earlier quoted context omitted.

Golf courses. Well, okay, this is my wonderful father's half serious answer that I love to retell. The basic idea is that it's easier to convince everyone that is actually 5:00pm and time to leave work than it is to convince just your boss that you want to start work an hour earlier and leave and hour earlier. This problem is then applied to politicians and other powerful people, who want to go golfing after work. If…

Are there really places that don't observe DST and also don't change their working hours? Just shift the working hours by a few hours when the seasons change. It also gives more granularity for the changes. If 1 week in the whole season is particularly cold, then change the time again for that 1 week.

> Are there really places that don't observe DST and also don't change their working hours?

Yes, literally every state/province in North America that doesn't observe DST. I don't know what goes on in Europe, but nobody in Arizona for example changes the open/close time of their barbershop, restaurant, or gas station solely due to the time the sun rises...

Re: Timezone Bullshit

#166

Post by dreamcompiler »

throw0101a wrote: post #52
Lvl999Noob wrote: post #43

Earlier quoted context omitted.

On the topic of DST... can you explain why some countries use DST? Anytime I look for the reasoning of it, it says that DST helps "make better use of daytime" but how? The earth isn't gonna say "Damn! These people changed their clocks. I better change by rotation and give them more sun time." Whether you have DST or not, you still have the same amount of time with sunlight in a day.

The closer one is to the poles, the more the number of hours of daylight shifts over the seasons. So at/near the equator, in a place like Panama, you will get roughly 12 hours of daylight in both the December and June Solstices. * https://www.timeanddate.com/sun/panama/panama Whereas in the Edinburgh you go from having 7 hours of daylight in December to over 17 hours in June: * https://www.timeanddate.com/sun/uk/edin…

..and the latitude where that 17 hours finally grows to 24 is called the Arctic Circle.

Re: Timezone Bullshit

#167

Post by eCa »

throwaway2245 wrote: post #116
sschueller wrote: post #28

I'm still hoping .beat time[1] will catch on but I have been waiting since 1998... I even made a watch-face for my smartwatch showing .beats [1] https://en.wikipedia.org/wiki/Swatch_Internet_Time

I'm guessing (from your name and enthusiasm) that you live in a place where 0 approximately corresponds to midnight? :)

It would be more fair to split a week into 6000 parts, that way everyone would have midnight at strange ”hours” but on different days.

Re: Timezone Bullshit

#168

Post by Unklejoe »

FabHK wrote: post #139
de_Selby wrote: post #20

Earlier quoted context omitted.

I'd say the moral is that server side should always be in UTC.

Unless sub-second accuracy is required, I'd be in favour of UT1. It doesn't use SI seconds (while TAI and UTC do), but it has the advantage that a day has exactly 86400 seconds, so you don't ever have to deal with "23:59:60" timestamps. Summary: UT1 - noon is when the sun is above you, day has 86400 seconds (not SI seconds) TAI - noon drifts away from when the sun is above you, day has 86400 SI seconds UTC - noon is…

I'd rather just use TAI and never have to worry about anything. Let the conversion to UTC be the client's problem.

Having the length of a second always be the same is kind of important.

Re: Timezone Bullshit

#169

Post by remram »

GoblinSlayer wrote: post #129
remram wrote: post #119

Earlier quoted context omitted.

Your argument sounds very similar to the "let's abolish timezones" argument so let me post this again: https://qntm.org/abolish Changing your schedule works for you and your boss, but does not let people in other parts of the world know when they can reach you. Officially shifting something is necessary, and then you might as well have timezones.

People in other parts of the world can reach me at any time by email, during the work hours of the email server.

If that is how everyone at your company feel, you don't need a schedule at all (or even a clock).

Re: Timezone Bullshit

#170

Post by jpitz »

majewsky wrote: post #95
qwertox wrote: post #78

What an important article to read. I've dealt over a decade with timezones, and this short article has shown me something new (EDT is not unique, gets silently set to UTC). I am in the habit of using "Country/City" on everything that is not UTC, so I never encountered this issue. But it's so good to know.

Nitpick: "Continent/City".

"America" isn't a continent.
Post reply on HN