In what timezone is this okay?

[PotatoEngineer]

@Gribnit said in In what timezone is this okay?:

@dkf iirc, so does the ECMAScript Date, for all the good it does.

developer.mozilla.org said:

Note: Parsing of date strings with the Date constructor (and Date.parse(), which works the same way) is strongly discouraged due to browser differences and inconsistencies.

• Support for RFC 2822 format strings is by convention only.
• Support for ISO 8601 formats differs in that date-only strings (e.g. "1970-01-01") are treated as UTC, not local.

So... it'll be mostly good, most of the time, until someone drops by with Lynx and insists that the dates are unforgivably wrong.

[boomzilla]

@Gribnit said in In what timezone is this okay?:

@boomzilla once you get a couple years in the field you'll learn how to serialize dates, don't worry.

Serialization is no problem at all. It's the deserialization that's causing problems.

[Zerosquare]

https://www.youtube.com/watch?v=1tVaMxyvjXA

[Luhmann]

@Zerosquare said in In what timezone is this okay?:

At first I read that as "Discourse had different timezones", and wasn't even surprised.

it sure works like it has a big mountain of fat on it

[Steve_The_Cynic]

@dkf said in In what timezone is this okay?:

@Steve_The_Cynic At least that's documented correctly, and you're given both a parser and a formatter.

It is accurately documented that it does something stupid, agreed.

[dkf]

@Steve_The_Cynic said in In what timezone is this okay?:

does something stupid

It's dealing with times and dates. Doing something stupid is a given.

[Steve_The_Cynic]

@boomzilla said in In what timezone is this okay?:

@Gribnit said in In what timezone is this okay?:

@boomzilla once you get a couple years in the field you'll learn how to serialize dates, don't worry.

Serialization is no problem at all. It's the deserialization that's causing problems.

Have you carefully examined the serialised buffer to make absolutely sure that it is serialised correctly?

I ask this because just a few days ago I got bitten by this same jolly fucknuttery about struct tm and its tm_mon field, and it turned out that the serialisation code (which did correct for similar fucknuttery about tm_year)(1) wasn't adjusting the month, and the deserialiser didn't think it needed to do the adjustment itself.

(1) tm_year is the "true" year minus 1900.

EDIT: the key point is that the passage via struct tm was an implementation detail of how the data was prepared for serialisation, and furthermore one that could not be used in the deserialisation process.

[boomzilla]

@Steve_The_Cynic said in In what timezone is this okay?:

@boomzilla said in In what timezone is this okay?:

@Gribnit said in In what timezone is this okay?:

@boomzilla once you get a couple years in the field you'll learn how to serialize dates, don't worry.

Serialization is no problem at all. It's the deserialization that's causing problems.

Have you carefully examined the serialised buffer to make absolutely sure that it is serialised correctly?

Uh...I looked at what the browser was sending over the network and according to the network tab it was the date in the format 'yyyy-mm-dd.

I ask this because just a few days ago I got bitten by this same jolly fucknuttery about struct tm and its tm_mon field, and it turned out that the serialisation code (which did correct for similar fucknuttery about tm_year)(1) wasn't adjusting the month, and the deserialiser didn't think it needed to do the adjustment itself.

(1) tm_year is the "true" year minus 1900.

EDIT: the key point is that the passage via struct tm was an implementation detail of how the data was prepared for serialisation, and furthermore one that could not be used in the deserialisation process.

No struct tms were harmed in the making of my code. Unless the JVM uses it, but I don't really care about that one way or the other.

[Steve_The_Cynic]

@boomzilla said in In what timezone is this okay?:

@Steve_The_Cynic said in In what timezone is this okay?:

@boomzilla said in In what timezone is this okay?:

@Gribnit said in In what timezone is this okay?:

@boomzilla once you get a couple years in the field you'll learn how to serialize dates, don't worry.

Serialization is no problem at all. It's the deserialization that's causing problems.

Have you carefully examined the serialised buffer to make absolutely sure that it is serialised correctly?

Uh...I looked at what the browser was sending over the network and according to the network tab it was the date in the format 'yyyy-mm-dd.

OK, fair enough.

I ask this because just a few days ago I got bitten by this same jolly fucknuttery about struct tm and its tm_mon field, and it turned out that the serialisation code (which did correct for similar fucknuttery about tm_year)(1) wasn't adjusting the month, and the deserialiser didn't think it needed to do the adjustment itself.

(1) tm_year is the "true" year minus 1900.

EDIT: the key point is that the passage via struct tm was an implementation detail of how the data was prepared for serialisation, and furthermore one that could not be used in the deserialisation process.

No struct tms were harmed in the making of my code. Unless the JVM uses it, but I don't really care about that one way or the other.

I was curious, so I looked up Java and dates. Now I have a headache. It looks like the deprecated java.util.Date has the same stupidity about starting month numbers at zero rather than at one. java.util.Calendar, in the docs at https://docs.oracle.com/javase/7/docs/api/java/util/Calendar.html , doesn't actually say what the range of month numbers is.

[Kamil Podlesak]

@dkf said in In what timezone is this okay?:

@PleegWat said in In what timezone is this okay?:

This is inconsistent with the observation that when the sun is below the horizon here it is well above the horizon in Australia.

Well obviously they're glued to the underside.

Occams razor, guys! The simplest solution is that Australia does not actually exist.

[Kamil Podlesak]

@Steve_The_Cynic said in In what timezone is this okay?:

I was curious, so I looked up Java and dates. Now I have a headache. It looks like the deprecated java.util.Date has the same stupidity about starting month numbers at zero rather than at one.

You got that backwards: Javascript Date is designed as a plain copy of the java.util.Date

java.util.Calendar, in the docs at https://docs.oracle.com/javase/7/docs/api/java/util/Calendar.html , doesn't actually say what the range of month numbers is.

It actually does say that the first month is JANUARY; the numeric value is not referenced in the same sentence, but it is in the documentation: https://docs.oracle.com/javase/7/docs/api/constant-values.html#java.util.Calendar.JANUARY
So, the value range starts at zero. Upper bound depends on the number of months in the calendar, which is left open.

[Jaime]

@bobjanova said in In what timezone is this okay?:

My preferred way of dealing with that these days is just to make all datetime values timestamps (Unix ones normally), which is effectively UTC, and then just have the UI deal with displays.

It's never this simple. For example, let's say your UI shows you when something happens. The record that shows this post being created is stored as 1:41pm, and is displayed as 8:41am here on the east coast of the United States. Next week, DST kicks in. I go look at the log record again... if you're not really careful, the UI might show 9:41am, which isn't when it actually happened.

[Steve_The_Cynic]

@Kamil-Podlesak said in In what timezone is this okay?:

@Steve_The_Cynic said in In what timezone is this okay?:

I was curious, so I looked up Java and dates. Now I have a headache. It looks like the deprecated java.util.Date has the same stupidity about starting month numbers at zero rather than at one.

You got that backwards: Javascript Date is designed as a plain copy of the java.util.Date

I didn't say anything about which was derived from what, actually. And the stupidity remains stupid, no matter which of them was the original stupidifier.

java.util.Calendar, in the docs at https://docs.oracle.com/javase/7/docs/api/java/util/Calendar.html , doesn't actually say what the range of month numbers is.

It actually does say that the first month is JANUARY; the numeric value is not referenced in the same sentence, but it is in the documentation: https://docs.oracle.com/javase/7/docs/api/constant-values.html#java.util.Calendar.JANUARY
So, the value range starts at zero. Upper bound depends on the number of months in the calendar, which is left open.

Ugh, I didn't read well enough. The expected values that you read with get(xxx) are documented in the various set(...) methods, and yes, it is, indeed zero-based for months.

[boomzilla]

@Steve_The_Cynic yes, the months are really stupid. I know I've ranted about the multiple times. You just have to remember to always use the constants and at least you'll know is going on and don't have to think about the zero based system for talking about one based things.

[sockpuppet7]

The Gregorian Calendar is stupid if you compared to the far superior 13 month calendar

Every month is equal, with 28 days, starting on a sunday and ending on a saturday

[Kamil Podlesak]

@Jaime said in In what timezone is this okay?:

@bobjanova said in In what timezone is this okay?:

My preferred way of dealing with that these days is just to make all datetime values timestamps (Unix ones normally), which is effectively UTC, and then just have the UI deal with displays.

It's never this simple. For example, let's say your UI shows you when something happens. The record that shows this post being created is stored as 1:41pm, and is displayed as 8:41am here on the east coast of the United States. Next week, DST kicks in. I go look at the log record again... if you're not really careful, the UI might show 9:41am, which isn't when it actually happened.

This would definitely be a bug in the conversion library: it is supposed to determine DST offset by the date value, for given zone. Actually, it is also expected that it uses correct rules that were in effect for that year, so the displayed time is not changed when the government decides next year that DST starts one week later.

[Jaime]

@Kamil-Podlesak But, by storing it in UTC, he destroyed the original time zone... so the display library can only use the current user's time zone, not the time zone of the actual time stamp. You get interesting bugs in this scenario when the activity and the user have different DST transition days.

It's also important to know whether we're displaying "when did it happen on my clock" or "when did it happen on his clock".

[Kamil Podlesak]

@Jaime said in In what timezone is this okay?:

@Kamil-Podlesak But, by storing it in UTC, he destroyed the original time zone... so the display library can only use the current user's time zone, not the time zone of the actual time stamp. You get interesting bugs in this scenario when the activity and the user have different DST transition days.

No, that is OK; original time zone is completely irrelevant. It's OK to display in current zone, but not current DST. In other words, it does not matter if the currently active time zone is EST or EDT - the library should treat both of them as EST and internally determine if the date belongs to EST or EDT. Any library that takes "EDT" just as an alias of UTC-4:00 is plain wrong.

[error]

@HardwareGeek said in In what timezone is this okay?:

Parallelizing dates is a really bad idea. The threading is very unsafe, unless they're into polyamory.

I'm seeing a girl who won't enter a relationship with me because she is "not poly," but she is dating three other guys.

I guess she is eventually-monogamous.

[boomzilla]

@error maybe the problem is that you're aware there are 3 other guys? But none of those 3 know about each other?

[error]

@boomzilla She seems to be running a multithreaded search for "the one."

I believe there are reality TV shows about this method.

[remi]

@Kamil-Podlesak said in In what timezone is this okay?:

@dkf said in In what timezone is this okay?:

@PleegWat said in In what timezone is this okay?:

This is inconsistent with the observation that when the sun is below the horizon here it is well above the horizon in Australia.

Well obviously they're glued to the underside.

Occams razor, guys! The simplest solution is that Australia does not actually exist.

I was planning to go to Australia last year Spring, and it just so happens that the airline found a reason to cancel my flight and I couldn't go. Coincidence? I think not!

[Gribnit]

@Steve_The_Cynic I remember following some set of links to UNDECIMBER at some point. Not sure how.

[Gribnit]

@sockpuppet7 said in In what timezone is this okay?:

The Gregorian Calendar is stupid if you compared to the far superior 13 month calendar

Every month is equal, with 28 days, starting on a sunday and ending on a saturday

In the 5-month calendar, each month is exactly 73 days.

[Zerosquare]

@error said in In what timezone is this okay?:

I'm seeing a girl who won't enter a relationship with me because she is "not poly,"

All users are @boomzilla, but not all users are @Polygeekery.

[dcon]

@Gribnit said in In what timezone is this okay?:

In the 5-month calendar, each month is exactly 73 days.

We can rename them Spring, Summer, Fall, Winter, LocalNameOfRegionalWeirdSeason. Winter-Frist will begin when the local winter begins. Brought to you by Bringing Time Zones To Seasons Inc.

[PleegWat]

@Gribnit said in In what timezone is this okay?:

@sockpuppet7 said in In what timezone is this okay?:

The Gregorian Calendar is stupid if you compared to the far superior 13 month calendar

Every month is equal, with 28 days, starting on a sunday and ending on a saturday

In the 5-month calendar, each month is exactly 73 days.

And today is Boomtime, the 67th day of Chaos in the YOLD 3187

[HardwareGeek]

@PleegWat said in In what timezone is this okay?:

@Gribnit said in In what timezone is this okay?:

@sockpuppet7 said in In what timezone is this okay?:

The Gregorian Calendar is stupid if you compared to the far superior 13 month calendar

Every month is equal, with 28 days, starting on a sunday and ending on a saturday

In the 5-month calendar, each month is exactly 73 days.

And today is Boomtime, the 67th day of Chaos in the YOLD 3187

It's always Boomtime at TDWTF.

[boomzilla]

@PleegWat said in In what timezone is this okay?:

Boomtime

https://youtu.be/pFriRcIwqNU

[hungrier]

@error said in In what timezone is this okay?:

@boomzilla She seems to be running a multithreaded search for "the one."

I believe there are reality TV shows about this method.

Are they anything like the Jet Li movie, or should I not even bother?

[Gribnit]

@hungrier said in In what timezone is this okay?:

@error said in In what timezone is this okay?:

@boomzilla She seems to be running a multithreaded search for "the one."

I believe there are reality TV shows about this method.

Are they anything like the Jet Li movie, or should I not even bother?

They are something like the Jet Li movie, in that they are more similar to yon movie than to say, a ham sandwich.