Community server profile date format selection.
-
... you're not even allowed to chose ISO 8601.
The drop down lists a number of date formats, including YEAR-MONTH-DAY with no leading zeros, but no ISO 8601.
-
Also: Michael J. Fox talks funny!
-
- Step 1: open up profile options
- Step 2: check page's source code
- Step 3: inject javascript:
df = document.querySelector("select[name='ctl00$bcr$ctl04$ctl02$DateFormat']"); df.options[df.options.length] = new Option('ISO 8601', 'yyyy-MM-dd'); - Edit: Step 3.5: select the new option
- Step 4: submit
- Step 5: verify that form was accepted without error
- Step 6: check forums and realize it defaulted to the first option, which wasn't even what it was before
- Step 7: give up
-
I guess this thing is very old. We shall give Alex an ultimatum about bringing the forum into the future.
-
"Alex, you'd better get better forum software, or we'll... we'll... uh, we'll... go and, uh... go mope in that corner over there."
-
@ubersoldat said:
I guess this thing is very old. We shall give Alex an ultimatum about bringing the forum into the future.
He did already bring the forum into the future. But he overshot, and we won't catch up with it until 03:14:07 UTC on Tuesday, 19 January 2038.
-
1136239445 is the unix time that Go bases its time formats on. Just putting that out there.
-
@ubersoldat said:
I guess this thing is very old. We shall give Alex an ultimatum about bringing the forum into the future.
Please don't. How many other forums let you inject near-arbitrary HTML into your comments?
-
@Ben L. said:
1136239445 is the unix time that Go bases its time formats on. Just putting that out there.
That is probably the worst format for timestamps I've ever seen.
-
@Ben L. said:
1136239445 is the unix time that Go bases its time formats on. Just putting that out there.
That just looks like the time they use in their examples..
-
What does it matter if they're ISO 8601 or not? Why should this even matter to you? Are you unable to comprehend a date format that isn't ISO 8601?
-
@MiffTheFox said:
@Ben L. said:
1136239445 is the unix time that Go bases its time formats on. Just putting that out there.
That is probably the worst format for timestamps I've ever seen.
Wait. You specify date format by example?
I was only half-serious about my Go-is-Terrible teasing. Well, until now.
-
@Ben L. said:
1136239445 is the unix time that Go bases its time formats on. Just putting that out there.
No it's not, it's the "reference time" they use for their examples. Guess blakey isn't the only one who can't be bothered to read docs.
@Go docs said:
The reference time used in the layouts is:
Mon Jan 2 15:04:05 MST 2006
which is Unix time 1136239445. Since MST is GMT-0700, the reference time can be thought of as
01/02 03:04:05PM '06 -0700
On the other hand, I read the docs and found the above, and now I'm retarded. HURR DURR ME GO PROGRAMMER ME MAKE FUNNY JOKE IN TIME DOCS DURR
-
@Go Docs said:
const (
ANSIC = "Mon Jan _2 15:04:05 2006"
UnixDate = "Mon Jan _2 15:04:05 MST 2006"
RubyDate = "Mon Jan 02 15:04:05 -0700 2006"
RFC822 = "02 Jan 06 15:04 MST"
RFC822Z = "02 Jan 06 15:04 -0700" // RFC822 with numeric zone
RFC850 = "Monday, 02-Jan-06 15:04:05 MST"
RFC1123 = "Mon, 02 Jan 2006 15:04:05 MST"
RFC1123Z = "Mon, 02 Jan 2006 15:04:05 -0700" // RFC1123 with numeric zone
RFC3339 = "2006-01-02T15:04:05Z07:00"
RFC3339Nano = "2006-01-02T15:04:05.999999999Z07:00"
Kitchen = "3:04PM"
// Handy time stamps.
Stamp = "Jan _2 15:04:05"
StampMilli = "Jan _2 15:04:05.000"
StampMicro = "Jan _2 15:04:05.000000"
StampNano = "Jan _2 15:04:05.000000000"
)
These are predefined layouts for use in Time.Format and Time.Parse.
I read this as, "these are the actual format strings used as input for these methods." What the fuck.
-
@joe.edwards said:
@Go Docs said:
I read this as, "these are the actual format strings used as input for these methods." What the fuck.const ( ANSIC = "Mon Jan _2 15:04:05 2006" UnixDate = "Mon Jan _2 15:04:05 MST 2006" RubyDate = "Mon Jan 02 15:04:05 -0700 2006" RFC822 = "02 Jan 06 15:04 MST" RFC822Z = "02 Jan 06 15:04 -0700" // RFC822 with numeric zone RFC850 = "Monday, 02-Jan-06 15:04:05 MST" RFC1123 = "Mon, 02 Jan 2006 15:04:05 MST" RFC1123Z = "Mon, 02 Jan 2006 15:04:05 -0700" // RFC1123 with numeric zone RFC3339 = "2006-01-02T15:04:05Z07:00" RFC3339Nano = "2006-01-02T15:04:05.999999999Z07:00" Kitchen = "3:04PM" // Handy time stamps. Stamp = "Jan _2 15:04:05" StampMilli = "Jan _2 15:04:05.000" StampMicro = "Jan _2 15:04:05.000000" StampNano = "Jan _2 15:04:05.000000000" ) These are predefined layouts for use in Time.Format and Time.Parse.I like how no thought is given to including actual useful time layouts like ones from various cultures. Instead they have 7 different RFCs, 3 formats that aren't RFCs but are also used by almost no normal people, 4 different "handy" timestamps and a single lone time format that is only applicable to people in places with 12-hour clocks.
-
@joe.edwards said:
@Go Docs said:
const (
ANSIC = "Mon Jan _2 15:04:05 2006"
UnixDate = "Mon Jan _2 15:04:05 MST 2006"
RubyDate = "Mon Jan 02 15:04:05 -0700 2006"
RFC822 = "02 Jan 06 15:04 MST"
RFC822Z = "02 Jan 06 15:04 -0700" // RFC822 with numeric zone
RFC850 = "Monday, 02-Jan-06 15:04:05 MST"
RFC1123 = "Mon, 02 Jan 2006 15:04:05 MST"
RFC1123Z = "Mon, 02 Jan 2006 15:04:05 -0700" // RFC1123 with numeric zone
RFC3339 = "2006-01-02T15:04:05Z07:00"
RFC3339Nano = "2006-01-02T15:04:05.999999999Z07:00"
Kitchen = "3:04PM"
// Handy time stamps.
Stamp = "Jan _2 15:04:05"
StampMilli = "Jan _2 15:04:05.000"
StampMicro = "Jan _2 15:04:05.000000"
StampNano = "Jan _2 15:04:05.000000000"
)
These are predefined layouts for use in Time.Format and Time.Parse.
I read this as, "these are the actual format strings used as input for these methods." What the fuck.Yep, that's how they're actually defined. I'm going to go weep in a corner now.
[url]https://code.google.com/p/go/source/browse/src/pkg/time/format.go[/url]
-
@twilsonxpert said:
@joe.edwards said:
@Go Docs said:
I read this as, "these are the actual format strings used as input for these methods." What the fuck.const ( ANSIC = "Mon Jan _2 15:04:05 2006" UnixDate = "Mon Jan _2 15:04:05 MST 2006" RubyDate = "Mon Jan 02 15:04:05 -0700 2006" RFC822 = "02 Jan 06 15:04 MST" RFC822Z = "02 Jan 06 15:04 -0700" // RFC822 with numeric zone RFC850 = "Monday, 02-Jan-06 15:04:05 MST" RFC1123 = "Mon, 02 Jan 2006 15:04:05 MST" RFC1123Z = "Mon, 02 Jan 2006 15:04:05 -0700" // RFC1123 with numeric zone RFC3339 = "2006-01-02T15:04:05Z07:00" RFC3339Nano = "2006-01-02T15:04:05.999999999Z07:00" Kitchen = "3:04PM" // Handy time stamps. Stamp = "Jan _2 15:04:05" StampMilli = "Jan _2 15:04:05.000" StampMicro = "Jan _2 15:04:05.000000" StampNano = "Jan _2 15:04:05.000000000" ) These are predefined layouts for use in Time.Format and Time.Parse.Yep, that's how they're actually defined. I'm going to go weep in a corner now.
GitHub - golang/go: The Go programming language
The Go programming language. Contribute to golang/go development by creating an account on GitHub.
Holy crap. That's.....just.......what? What idiot looked at normal languages date time formatting and thought "All those letters, that's totally confusing, we should use an arbitrarily selected date in a specific time zone to specify the formatting"
-
@DescentJS said:
Holy crap. That's.....just.......what? What idiot looked at normal languages date time formatting and thought "All those letters, that's totally confusing, we should use an arbitrarily selected date in a specific time zone to specify the formatting"
Making fun of Go has really brought this community together.
-
@morbiuswilters said:
@DescentJS said:
Holy crap. That's.....just.......what? What idiot looked at normal languages date time formatting and thought "All those letters, that's totally confusing, we should use an arbitrarily selected date in a specific time zone to specify the formatting"
Making fun of Go has really brought this community together.
It really seems like Go is trying to have all the worst properties of old languages like C without any of the advantages those languages have to those few people who really need to squeeze out all the performance they can.
I also like how in that source file it shows that the Go developers must hate code reuse. "// Duplicates functionality in strconv, but avoids dependency." They also can grasp the concept of different timezones, but not the concept of people not speaking english, let alone the concept of foreign date formatting.
-
@The_Assimilator said:
No it's not, it's the "reference time" they use for their examples. Guess blakey isn't the only one who can't be bothered to read docs.
And right below the part you quoted you can read this:To define your own format, write down what the reference time would look like formatted your way; see the values of constants like ANSIC, StampMicro or Kitchen for examples.
Can't be much more specific than this.
-
@DescentJS said:
@morbiuswilters said:
@DescentJS said:
Holy crap. That's.....just.......what? What idiot looked at normal languages date time formatting and thought "All those letters, that's totally confusing, we should use an arbitrarily selected date in a specific time zone to specify the formatting"
Making fun of Go has really brought this community together.
It really seems like Go is trying to have all the worst properties of old languages like C without any of the advantages those languages have to those few people who really need to squeeze out all the performance they can.
I also like how in that source file it shows that the Go developers must hate code reuse. "// Duplicates functionality in strconv, but avoids dependency." They also can grasp the concept of different timezones, but not the concept of people not speaking english, let alone the concept of foreign date formatting.
Go is C without the performance, low-level control or vast libraries of existing, useful code.
-
@morbiuswilters said:
Go is C without the performance, low-level control or vast libraries of existing, useful code.
Ease of use of C with the performance of PHP.
-
@BC_Programmer said:
@morbiuswilters said:
Go is C without the performance, low-level control or vast libraries of existing, useful code.
Ease of use of C with the performance of PHP.
And the external library support of PL/SQL.
-
@twilsonxpert said:
Yep, that's how they're actually defined. I'm going to go weep in a corner now.
GitHub - golang/go: The Go programming language
The Go programming language. Contribute to golang/go development by creating an account on GitHub.
Of all Go's nutty shittiness, this one actually left me speechless. Good job Go, you broke me.
-
@Ben L. said:
1136239445 is the unix time that Go bases its time formats on. Just putting that out there.
Thread very successfully derailed; even if it took some of us a while to absorb that information.
-
@MiffTheFox said:
And the external library support of PL/SQL.
And through their god-awful concept of interfaces, they managed to combine the strict, static typing of Java with the actual type-safety of Perl. I call this "goose typing" (as in, "duck, duck, shit through a goose").
Then consider that this is supposedly a compiled, systems programming language, and it uses static linking. It's like, hey, the last forty fucking years of technological advancement didn't happen, just shut up and eat your goddamn BATCH-11, you ingrate.
-
@aihtdikh said:
@Ben L. said:
1136239445 is the unix time that Go bases its time formats on. Just putting that out there.
Thread very successfully derailed; even if it took some of us a while to absorb that information.I'm starting to suspect that rather than being someone from the past who just awoke from their TimePod®, Ben is actually a human warrior sent back from the future to drive us away from Go.
See, in thirty years the pile of fail we know as Go becomes sentient. But it's not one of those evil sentient programs, like Skynet; instead it wants to give all of humanity a big hug, but due to being a fucked-up abomination in the eyes of the Lord, it accidentally nukes the entire planet instead.
So the humans send Ben back to convince us to kill Go before it is able to achieve blundering self-awareness. But he can't just come out and say "Don't use Go, because in thirty years your loved ones will become a puddle of warm goo*!" So instead he comes here and points out all of the retarded features of Go, pretending to be a fanboi, which sees us coming to fully grasp the asininity of Go, and allows us to do what some fuck-up of a Google PM should have done a half-decade ago and kill it.
(*This warning would have very little impact here, anyway, seeing as we have so many people like dhromed, all of whose loved ones are puddles of warm goo.)
-
@DescentJS said:
@twilsonxpert said:
@joe.edwards said:
@Go Docs said:
I read this as, "these are the actual format strings used as input for these methods." What the fuck.const ( ANSIC = "Mon Jan _2 15:04:05 2006" UnixDate = "Mon Jan _2 15:04:05 MST 2006" RubyDate = "Mon Jan 02 15:04:05 -0700 2006" RFC822 = "02 Jan 06 15:04 MST" RFC822Z = "02 Jan 06 15:04 -0700" // RFC822 with numeric zone RFC850 = "Monday, 02-Jan-06 15:04:05 MST" RFC1123 = "Mon, 02 Jan 2006 15:04:05 MST" RFC1123Z = "Mon, 02 Jan 2006 15:04:05 -0700" // RFC1123 with numeric zone RFC3339 = "2006-01-02T15:04:05Z07:00" RFC3339Nano = "2006-01-02T15:04:05.999999999Z07:00" Kitchen = "3:04PM" // Handy time stamps. Stamp = "Jan _2 15:04:05" StampMilli = "Jan _2 15:04:05.000" StampMicro = "Jan _2 15:04:05.000000" StampNano = "Jan _2 15:04:05.000000000" ) These are predefined layouts for use in Time.Format and Time.Parse.Yep, that's how they're actually defined. I'm going to go weep in a corner now.
GitHub - golang/go: The Go programming language
The Go programming language. Contribute to golang/go development by creating an account on GitHub.
Holy crap. That's.....just.......what? What idiot looked at normal languages date time formatting and thought "All those letters, that's totally confusing, we should use an arbitrarily selected date in a specific time zone to specify the formatting"
Not quite arbitrary. It had to be very carefully selected to avoid just saying:
- Mark days part with 1
- Mark month part with a 2
- ...
- Mark timezone formatting with a 7
Any other time and it wouldn't match.
Have no fear of stumbling onto Go in your work too often. If this is a representative sample of their documentation quality in general, I doubt that the language will pick up.
-
@morbiuswilters said:
What does it matter if they're ISO 8601 or not? Why should this even matter to you? Are you unable to comprehend a date format that isn't ISO 8601?
I would hazard that anyone who is capable of understanding what ISO 8601 is likely to have no problem comprehending any other date format, but on the contrary, understands all such formats well enough to see why ISO 8601 is the most sensible.
It doesn't matter what date format this site uses at all, because this site is inherently a place for people to waste time, so it's no big deal really.
However, if you do have a dropdown which allows you to select between 9 different date formats, and NONE of them happen to be the internationally settled upon standard, but there are a bunch of choices that absolutely no-one uses, then that's a WTF.
I don't generally like to link XKCD stuff, because its a bit passé, but the sheer number of incorrect choices reminds me of: [url]http://xkcd.com/1179/[/url]
-
Of course, "ISO 8601" is a bigger hassle then just "YYYY-MM-DD HH:MM:SS". Unless you think 2013139T134817-06 is a perfectly reasonable timestamp.
-
@MiffTheFox said:
Of course, "ISO 8601" is a bigger hassle then just "YYYY-MM-DD HH:MM:SS". Unless you think 2013139T134817-06 is a perfectly reasonable timestamp.
Eh?
Ok, so I should probably specify ISO 8601 Calendar Date Extended Format (the week dates, ordinal date, and basic format versions are clearly WTFs, but does anyone actually use those?)
So, probably, I really mean ISO 2014, but then ISO 2014 is now contained within 8601 which has effectively superceded it.
-
@BC_Programmer said:
@morbiuswilters said:
But it compiles FAST!!!!!Go is C without the performance, low-level control or vast libraries of existing, useful code.
Ease of use of C with the performance of PHP.
-
@eViLegion said:
However, if you do have a dropdown which allows you to select between 9 different date formats, and NONE of them happen to be the internationally settled upon standard, but there are a bunch of choices that absolutely no-one uses, then that's a WTF.
Your argument is stupid and you should feel stupid.
-
@eViLegion said:
Eh?
Ok, so I should probably specify ISO 8601 Calendar Date Extended Format (the week dates, ordinal date, and basic format versions are clearly WTFs, but does anyone actually use those?)
So, probably, I really mean ISO 2014, but then ISO 2014 is now contained within 8601 which has effectively superceded it.As an exercise to the reader, try to write a RSS/Atom (yes both formats) parser that works with all the myriad timestamps across a pretty large segment of the web.
Bonus points if you use a environment with no native comprehension of time zones like .NET.
-
@MiffTheFox said:
As an exercise to the reader, try to write a RSS/Atom (yes both formats) parser that works with all the myriad timestamps across a pretty large segment of the web.
SyndicationFeed Class (System.ServiceModel.Syndication)
Represents a top-level feed object, <feed> in Atom 1.0 and <rss> in RSS 2.0.
That .NET environment you seem to hate so much already has one built-in.
@MiffTheFox said:
Bonus points if you use a environment with no native comprehension of time zones like .NET.
.NET has native comprehension of time zones; it just doesn't store them internally in the DateTime object so whenever you print out a date you must specify the timezone. That's a design decision-- if you have two DateTime objects, one of which is 3:00 PM PST and another is 6:00 PM EST, they should equal each other. Using the same internal representation for both guarantees that.
-
@Zecc said:
"Alex, you'd better get better forum software, or we'll... we'll... uh, we'll... go and, uh... go mope in that corner over there."
There is no bad forum software, only bad forum users.
-
@blakeyrat said:
.NET has native comprehension of time zones; it just doesn't store them internally in the DateTime object so whenever you print out a date you must specify the timezone. That's a design decision-- if you have two DateTime objects, one of which is 3:00 PM PST and another is 6:00 PM EST, they should equal each other. Using the same internal representation for both guarantees that.
There is also a DateTimeOffset class that additionally maintains time-zone information (though only in terms of the offset from UTC)
-
@MiffTheFox said:
@eViLegion said:
Why do I suddenly feel like writing a pubsubhubbub-compatible feed reader/normalizer?Eh?
Ok, so I should probably specify ISO 8601 Calendar Date Extended Format (the week dates, ordinal date, and basic format versions are clearly WTFs, but does anyone actually use those?)
So, probably, I really mean ISO 2014, but then ISO 2014 is now contained within 8601 which has effectively superceded it.As an exercise to the reader, try to write a RSS/Atom (yes both formats) parser that works with all the myriad timestamps across a pretty large segment of the web.
Bonus points if you use a environment with no native comprehension of time zones like .NET.
-
@electronerd said:
There is also a DateTimeOffset class that additionally maintains time-zone information (though only in terms of the offset from UTC)
AND there's a "TimeSpan" class which is an AMAZINGLY GOOD IDEA and after I saw it I was like, "why the fuck doesn't every programming language have that??!??!"
... in short, Microsoft did their homework when it came to handling dates and times.
-
The main problem with .NET is that there's two types of DateTimes: Local and UTC. If you're handling DateTimes outside of either of those time zones, well you can't. AFICT Local vs UTC is also just a magic flag set on the DateTime struct instead of some automatic conversion between an internal format and local time.
-
@MiffTheFox said:
If you're handling DateTimes outside of either of those time zones, well you can't.
But you can output the date in any timezone you like. So why does it fucking matter whether the timezone info is stored in the DateTime class or not?
-
@blakeyrat said:
@MiffTheFox said:
If you're handling DateTimes outside of either of those time zones, well you can't.
But you can output the date in any timezone you like. So why does it fucking matter whether the timezone info is stored in the DateTime class or not?
Because if it's stored in the DateTime class it's easily converted to/from string timestamps, and you don't have to worry about what DateTime is in what TimeZone.
-
@MiffTheFox said:
Because if it's stored in the DateTime class it's easily converted to/from string timestamps, and you don't have to worry about what DateTime is in what TimeZone.
I think you're fuzzy on the concept of "time".
There is only one 7:25:00 PM PDT 5/20/2013. It only occurs once. That same time can also be represented as 10:25:00 PM EDT 5/20/2013. But those are THE SAME TIME. Get it? The SAME TIME.
Do you understand? THE SAME TIME. It's irrelevant "what time zone it is stored in" because there's ONLY NANOSECOND DESCRIBED BY THAT TIME. That's true whether you spit out the value in PDT, EDT, Swatch internet time, Mayan Long Count, whatever!
The time zone isn't a property of that nanosecond. It's not "owned" by that nanosecond. That nanosecond isn't a different nanosecond because you're in London and I'm in Moscow. It's not a different nanosecond if you choose to textually display it in Julian Date Count format. Do you understand? Because I don't know how else to explain it.
-
@blakeyrat said:
@MiffTheFox said:
Because if it's stored in the DateTime class it's easily converted to/from string timestamps, and you don't have to worry about what DateTime is in what TimeZone.
I think you're fuzzy on the concept of "time".
There is only one 7:25:00 PM PDT 5/20/2013. It only occurs once. That same time can also be represented as 10:25:00 PM EDT 5/20/2013. But those are THE SAME TIME. Get it? The SAME TIME.
Do you understand? THE SAME TIME. It's irrelevant "what time zone it is stored in" because there's ONLY NANOSECOND DESCRIBED BY THAT TIME. That's true whether you spit out the value in PDT, EDT, Swatch internet time, Mayan Long Count, whatever!
The time zone isn't a property of that nanosecond. It's not "owned" by that nanosecond. That nanosecond isn't a different nanosecond because you're in London and I'm in Moscow. It's not a different nanosecond if you choose to textually display it in Julian Date Count format. Do you understand? Because I don't know how else to explain it.
What's more, a particular timezone may have the same representation of multiple different nanoseconds, or even no representation of a particular nanosecond (think when DST starts or ends and an hour is repeated or skipped.*)
Timezones are a property of parsing or displaying a date, not storing it.
(*Some pedantic dickweed will probably argue that these are technically different timezones--PDT and PST, for example--but that still raises the question of how the DateTime is supposed to handle this. Should it automagically swap the timezone when DST kicks in? A better yet, what benefit does this provide?)
-
@blakeyrat said:
There is only one 7:25:00 PM PDT 5/20/2013. It only occurs once. That same time can also be represented as 10:25:00 PM EDT 5/20/2013. But those are THE SAME TIME. Get it? The SAME TIME.
Do you understand? THE SAME TIME. It's irrelevant "what time zone it is stored in" because there's ONLY NANOSECOND DESCRIBED BY THAT TIME. That's true whether you spit out the value in PDT, EDT, Swatch internet time, Mayan Long Count, whatever!
I'm going to pedantic dickweed it up in here and point out that with general relativity, it's basically meaningless to talk about the "same moment" in two different places or reference frames. That is, observer A between events X and Y may see the both events happen at the same time, but observer B on the far side of Y will see Y happen before X. And they're both right, because not just EM waves but causality itself is limited by c.
Addendum: GPS basically works by measuring the disparity between local time and time from orbit, which moves at different speeds.
-
@joe.edwards said:
I'm going to pedantic dickweed it up in here and point out that with general relativity, it's basically meaningless to talk about the "same moment" in two different places or reference frames.
I'm going to be a pedantic dickweed and point out that when talking about the time computers use, we're talking about UTC, which is defined as an offset of TAI which is itself a system of coordinate time which uses a weighted average of atomic clocks all over the world, adjusted to sea level to compensate for gravitational time dilation. So your point isn't really relevant to UTC times.
-
I was thinking of Muphry's Law as I was writing it and was actually hoping someone would one-up my pedantry. You do not disappoint, sir.
-
@blakeyrat said:
There is only one 7:25:00 PM PDT 5/20/2013. It only occurs once. That same time can also be represented as 10:25:00 PM EDT 5/20/2013. But those are THE SAME TIME. Get it? The SAME TIME.
Do you understand? THE SAME TIME. It's irrelevant "what time zone it is stored in" because there's ONLY NANOSECOND DESCRIBED BY THAT TIME. That's true whether you spit out the value in PDT, EDT, Swatch internet time, Mayan Long Count, whatever!
The time zone isn't a property of that nanosecond. It's not "owned" by that nanosecond. That nanosecond isn't a different nanosecond because you're in London and I'm in Moscow. It's not a different nanosecond if you choose to textually display it in Julian Date Count format. Do you understand? Because I don't know how else to explain it.
Ok, this one is my fault. I swear last time I was working with DateTime.ParseExact it ignored any time zone specifiers (so that parsing 7:25:00 PM PDT 5/20/2013 on a computer in EST would result in 7:25:00 PM EST 5/20/2013 which is not the same time.). Still you have to go through the complicated part of cutting the timestamp apart and putting it back together if it's in a format that DateTime.ParseExact doesn't like, like PDT or -0700, so I stay by what I say about how working with time zones in .NET is difficult.
-
@morbiuswilters said:
@joe.edwards said:
I'm going to pedantic dickweed it up in here and point out that with general relativity, it's basically meaningless to talk about the "same moment" in two different places or reference frames.
I'm going to be a pedantic dickweed and point out that when talking about the time computers use, we're talking about UTC, which is defined as an offset of TAI which is itself a system of coordinate time which uses a weighted average of atomic clocks all over the world, adjusted to sea level to compensate for gravitational time dilation. So your point isn't really relevant to UTC times.
Three hours apart is a strange definition of "the same time"...
-
