mIRC Home    About    Download    Register    News    Help

Print Thread
Joined: Aug 2006
Posts: 167
P
Vogon poet
OP Offline
Vogon poet
P
Joined: Aug 2006
Posts: 167
Am using mIRC 7.1, am in the -0800 (PDT) time zone, and have noticed that the following:

$asctime(1281835119,zzz)
$gmt(1281835119,zzz)
$time(1281835119,zzz)
$date(1281835119,zzz)

all return "-0800 GMT".

Something seems wrong here. smile Not sure about $time and $date, but shouldn't at least $asctime be returning "-0800 PDT", and $gmt, "+0000 GMT"?

Joined: Oct 2004
Posts: 8,330
Hoopy frood
Offline
Hoopy frood
Joined: Oct 2004
Posts: 8,330
$gmt isn't meant to take a value. When you include a value, it's treated like the other time/date methods. Maybe it should just error out, but it shouldn't show +0000 GMT. zzz will always be your time zone.


Invision Support
#Invision on irc.irchighway.net
Joined: Aug 2006
Posts: 167
P
Vogon poet
OP Offline
Vogon poet
P
Joined: Aug 2006
Posts: 167
I understand. Still, "-0800 GMT" is a nonsensical result in any case. GMT is not in the -0800 time zone, in other words...

Joined: Jan 2003
Posts: 2,523
Q
Hoopy frood
Offline
Hoopy frood
Q
Joined: Jan 2003
Posts: 2,523
It makes sense if you consider that z (zz/zzz) always return your current timezone, regardless of the (optional) N parameter or whether you used $gmt or $asctime. Having $gmt(zzz) return "+0000 GMT" wouldn't be terribly useful anyway.

wrt PDT, the format is always "+/-HHNN GMT", meaning "plus/minus hours/mins from GMT"

Last edited by qwerty; 15/08/10 02:01 AM.

/.timerQ 1 0 echo /.timerQ 1 0 $timer(Q).com
Joined: Aug 2006
Posts: 167
P
Vogon poet
OP Offline
Vogon poet
P
Joined: Aug 2006
Posts: 167
Hmm.

I guess the reason this struck me as "broken" is that when dealing with traditional time syntax as presented by software like e-mail/usenet clients, OS log files, or what have you, it is customary -- when a timezone is given simultaneously in abbreviated form (e.g. GMT) and offset form (e.g. +0000) -- for both to refer to the same timezone.

In other words, you never see "-0800 (GMT)" because that would be pointless; everyone already knows that offsets like -8 are always relative to GMT because GMT is world time. smile So, rather, when one sees "-0800 (XXX)", the XXX is there for redundancy, to elaborate upon which timezone -0800 happens to be (as well as to also indicate daylight vs. standard time). E.g., "-0800 (PDT)", telling you that in this case, -0800 means pacific time on daylight savings.

Anyway, that's the convention I've always been accustomed to. So in a sense, assuming $ctime currently = 1281918908 and my OS is configured for the -0800 timezone, when I do (and get) this ...

$asctime($ctime,ddd dd mmm yyyy HH:nn:ss zzz) = Sun 15 Aug 2010 16:35:08 -0800 GMT
$gmt($ctime,ddd dd mmm yyyy HH:nn:ss zzz) = Mon 16 Aug 2010 00:35:08 -0800 GMT

... the results appear broken. $asctime is showing me my current OS time with the correct timezone offset but with the incorrect timezone abbreviation; while $gmt is showing me my OS time as converted to GMT, with the incorrect timezone offset and the correct timezone abbreviation.

Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
"-0800 (GMT)" is very different from "-0800 GMT". It might seem subtle to you, but the latter is referring to -0800 in reference to GMT. Yes, this might seem redundant, but there's a difference between redundant and confusing. If anything, the GMT should make it *more* clear that -0800 is a timezone offset, not less.

mIRC does not list "-0800 (GMT)". If it did, I could see why this would confuse you into thinking "GMT" was the shortname for the timezone. This is not what mIRC is doing, since the GMT is not in parens.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Joined: Dec 2002
Posts: 344
D
Pan-dimensional mouse
Offline
Pan-dimensional mouse
D
Joined: Dec 2002
Posts: 344
I sort of agree that the 'zzz' format is a bit strange, to the point that I would probably avoid it altogether personally. Instead, I would just stick with 'zz' or 'z'.

I believe the most standard timezone notation is of the form "UTC-5", "UTC-05", and "UTC-05:00". As such, it might make more sense to design $asctime, et al., like so:

Code:
z    ==>  -5        +10       -3:30
zz   ==>  -05       +10       -03:30
zzz  ==>  -05:00    +10:00    -03:30

u    ==>  UTC


Then, you can use 'uz', 'uzz', or 'uzzz' to get formats like "UTC-5", "UTC-05", or "UTC-05:00", respectively. The 'u' shortcut would be handy since 'm' and 't' are already reserved for month and AM/PM.

I don't think this change is necessary, but just that it would be more consistent with standard notation.

Joined: Aug 2010
Posts: 19
U
Pikka bird
Offline
Pikka bird
U
Joined: Aug 2010
Posts: 19
Originally Posted By: argv0
"-0800 (GMT)" is very different from "-0800 GMT". It might seem subtle to you, but the latter is referring to -0800 in reference to GMT.

In what sphere of influence? I've never before known a time-zone initialism to mean anything other than the relevant local time zone. Nor is there generally any need to specify that the offset is UTC. (In fact ISO 8601 doesn't specify time-zone designators at all—only the offset, which is always relative to UTC.)

(Side note: Even though UTC never differs from GMT by more than one second, the reference used for time-syncing is UTC.)

What is the point of the zzz descriptor, if it only ever yields "GMT"? One could just as easily specify that literally. Unfortunately the manual is vague about the intended output; but mIRC is the first date formatter that i've seen exhibit this behaviour.


Irgendwo über dem Regenbogen
Joined: Oct 2004
Posts: 8,330
Hoopy frood
Offline
Hoopy frood
Joined: Oct 2004
Posts: 8,330
Originally Posted By: uberRegenbogen
What is the point of the zzz descriptor, if it only ever yields "GMT"?


zzz will show your offset followed by GMT. For example -0500 GMT, which is stating "-5 hours from GMT". If it showed the time zone "code" in parentheses, then it would mean that is your current time zone :: -0500 (EST), which is stating "-5 hours which is the EST time zone". That's what the parentheses mean.

Yes, you can manually insert GMT there. Some may not want to manually do that. zz lets you display just -0500 if you really don't want to see GMT and z lets you just display is as -5. I don't see any reason to change that.

If any change were considered, I'd look at adding zzzz or something else that would show it as -0500 (EST) and leave zzz as it is. I'm not sure how easy that would be, though. Considering it isn't always EST... it might be EDT depending on daylight savings. I'm not sure if that's easy to grab for mIRC. If it's not too difficult, I wouldn't mind seeing that as an additional option, but definitely don't think we need to remove or replace the existing options.


Invision Support
#Invision on irc.irchighway.net
Joined: Dec 2002
Posts: 344
D
Pan-dimensional mouse
Offline
Pan-dimensional mouse
D
Joined: Dec 2002
Posts: 344
I think the real point is that instead of the form "-0500 GMT", it should instead be the form "UTC-05:00" or one of the variations I listed in my last post. The fact of the matter is that "-0500 GMT" is simply NOT a usual way to notate a timezone, whether there are parentheses or not.

By the way, the use of timezone names like "EST" and "PST" is really not a good idea because these can have different meanings throughout the world. These are really only meaningful when used internally within a specific country or region.

Joined: Aug 2010
Posts: 19
U
Pikka bird
Offline
Pikka bird
U
Joined: Aug 2010
Posts: 19
Originally Posted By: drum
the use of timezone names like "EST" and "PST" is really not a good idea because these can have different meanings throughout the world. These are really only meaningful when used internally within a specific country or region.

Which is the purpose of the offset figure—to eliminate any ambiguity. Determining the local time-zone name is a simple matter of asking the OS for it—which is possible under Windows, at least for the current day. (Windows is not equipped to provide reliable time-zone info, for days outside of the observance of the current rules (e.g. before the recent DST threshhold changes in the US); but that's another issue.)


Irgendwo über dem Regenbogen

Link Copied to Clipboard